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MEMORANDUM  FOR  SECRETARIES  OF  THE  MUJTARY  DEPARTMENTS 

CHAIRMAN  OF  THE  JOINT  CHIEFS  OF  STAFF 
UNDER  SECRETARIES  OF  DEFENSE 
ASSISTANT  SECRETARIES  OF  DEFENSE 
GENERAL  COUNSEL  OF  THE  DEPARTMENT  OF  DEFENSE 
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DEFENSE 

DIRECTORS  OF  DEFENSE  AGENCIES 


SUBJECT;  The  New  DoD  Regulation  5000.2-R 


The  Department's  new  vision  for  acquisition  was  published  in  DoD  Directive 
5000.1  and  DoD  Instruction  5000.2,  effective  October  23,  2000.  We  also  published 
interim  guidance  (conforming  to  the  new  policy)  for  the  DoD  Regulation  5000.2-R  while 
we  completed  work  on  the  revised  regulation.  That  third  piece  of  the  DoD  5000  policy 
series  is  now  complete  and  is  attached  for  immediate  implementation.  This 
memorandum  outlines  my  view  for  putting  our  new  vision  into  practice. 

DoD's  new  acquisition  vision  provides  a  process  that  promotes  the  kind  of 
acquisition,  technology,  and  logistics  excellence  that  enables  us  to  maintain  our 
technological  superiority  by  fielding  (to  our  users)  the  best  systems  with  available 
technologies  that  are  supportable,  interoperable,  and  affordable  in  less  time  and  at  less 
cost.  In  changing  our  strategy  for  systems  development  and  acquisition,  as  outlined  in 
our  new  DoD  5000  policy  documents,  my  objective  is  to  reduce  cycle  time  and  achieve 
an  average  of  five  to  .seven  years  from  program  launch  to  production.  My  staff  is 
developing  a  set  of  metrics  to  measure  our  progress.  1  will  provide  additional  information 
on  our  metrics  in  a  separate  memorandum. 

Achieving  these  goals  will  require  us  to  change  the  way  we  think  about  new 
systems.  We  will  have  to  rely  more  heavily  on  commercial  technologies  and  products, 
particularly  in  our  subsystems  and  components.  This  will  require  much  more  market 
research  and  a  willingness  to  use  the  cost-as-an-independent-variable  process  to  work 
with  the  requirements  community  to  adjust  performance  parameters  based  on  the  results 
of  that  market  research.  We  also  have  to  move  forward  through  the  development  process 
based  upon  accumulating  knowledge  that  is  validated  by  simulation  or  test. 
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We  must  also  take  on  new  roles.  The  science  and  technology  community  must  be 
more  actively  engaged  in  enabling  the  rapid  transition  of  mature  technologies  to  product 
developers  and  must  actively  participate  in  integrated  product  teams  where  technology 
managers  can  provide  independent  assessments  of  technology  maturity.  The  system 
development  and  requirements  communities  must  be  more  willing  to  create  evolutionary 
strategies  in  order  to  deploy  systems  more  quickly  and  then  update  them  as  more 
advanced  technology  is  proven.  The  test  and  evaluation  community  must  capitalize  on 
the  benefils  of  using  modeling  and  simulation  throughout  the  acquisition  process  to 
facilitate  learning  during  development,  and  must  ensure  that  confirmation  tests  align  with 
evolutionary  requirements.  The  support  community  must  be  more  open  to  innovative 
support  strategics  that  focus  on  availability  and  innovation,  and  less  on  traditional 
approaches.  In  short,  we  must  change  our  organizational  culture  and  environment. 

Doing  business  as  we  have  in  the  past  will  not  allow  DoD  to  continue  to  put 
superior  systems  into  the  hands  of  our  users.  We  must  adopt  a  new  business  approach 
with  revolutionary  changes  in  business  practices  aimed  at  obtaining  a  force  that  is  more 
mobile,  lethal,  and  easily  supportable  by  incorporating  today's  best  technologies  and 
leaping  ahead  to  generation-after-next  technologies  in  order  to  maintain  superiority.  We 
now  have  the  policy  tools  and  a  more  flexible  process  that  facilitates  streamlined  decision 
making  to  support  our  vision  of  acquisition,  technology,  and  logistics  excellence.  To 
focus  senior  leadership  attention  and  reduce  decision  delay,  T  have  restructured  the 
Defense  Acquisition  Board  (DAB)  to  include  the  Service  Secretaries  and  have  decreased 
overall  DAB  membership.  However,  our  policy  documents  and  new  process  do  not 
provide  all  of  the  answers  on  how  to  operate.  We  will  continue  to  learn  as  we  go,  using  a 
process  of  catalytic  change  in  which  we  will  develop  the  right  procedures  as  we  strive  to 
achieve  our  objectives.  To  accomplish  this  goal,  we  all  will  have  to  apply  our  best 
judgements  and  common  sense  in  structuring  acquisition  strategics.  Together  we  must 
seize  this  opportunity.  We  can  do  no  less  for  our  soldiers,  sailors,  airmen,  and  marines. 


1  look  forward  to  youi  active  support  of  our  new  process,  and  your  participation, 
as  we  work  together  to  make  our  vision  of  acquisition,  technology,  and  logistics 
excellence  a  reality. 


Attachment: 
As  stated 
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FOREWORD 


This  Regulation  is  issued  under  the  authority  of  Department  of  Defense  (DoD) 
Instruction  5000.2,  “Operation  of  the  Defense  Acquisition  System,”  October  23, 2000 
(reference  (a))  and  is  effective  immediately.  This  Regulation  sets  forth  mandatory 
procedures  for  Major  Defense  Acquisition  Programs  (MDAPs)  and  Major  Automated 
Information  System  (MAIS)  acquisition  programs  and,  specifically  where  stated,  for 
other  than  MDAPs  or  MAIS  acquisition  programs;  serves  as  a  general  model  for  other 
than  MDAPs  or  MAIS  acquisition  programs  to  include  highly  sensitive  classified, 
cryptologic,  and  intelligence  programs;  implements  DoD  Instruction  5000.2  (reference 
(a)),  the  guidelines  of  Office  of  Management  and  Budget  (0MB)  Circular  A-1 1 
(reference  (b)),  and  current  statutes;  and  contains  formats  to  be  used  to  prepare  various 
milestone  documentation,  periodic  in-phase  status  reports,  and  statutory  certifications. 

This  Regulation  applies  to  the  Office  of  the  Secretary  of  Defense,  the  Military 
Departments,  the  Chairman  of  the  Joint  Chiefs  of  Staff,  the  Combatant  Commands,  the 
Defense  Agencies,  and  DoD  Field  Activities  (hereafter  collectively  referred  to  as  "DoD 
Components"). 

No  DoD  Component  shall  supplement  this  Regulation.  DoD  Component  officials 
shall  keep  the  issuance  of  implementing  documents  to  a  minimum,  and  provide  copies  of 
all  such  issuances  to  the  Under  Secretary  of  Defense  (Acquisition,  Technology,  and 
Logistics)  (USD(AT&L))  prior  to  publication.  DoD  Component  Acquisition  Executives 
(CAEs)  shall  submit  waivers  or  other  requests  for  exceptions  to  the  provisions  of  this 
Regulation  to  USD(AT&L),  the  Director,  Operational  Test  &  Evaluation  (DOT&E),  or 
the  Assistant  Secretary  of  Defense  (Command,  Control,  Communications,  and 
Intelligence)  (ASD(C3I))/DoD  Chief  Information  Officer  (CIO),  as  appropriate. 
Signatories  shall  not  waive  statutory  requirements  except  in  compliance  with,  and  unless, 
statute  specifically  allows  such  waiver.  DoD  Components  shall  forward  copies  of 
proposed  policy  memoranda  affecting  or  related  to  individual  sections  of  this  Regulation 
to  the  Defense  Acquisition  Policy  Steering  Group  (DAPSG)  Executive  Secretary  prior  to 
Department-wide  staffing  of  the  change.  This  policy  shall  not  imply  approval  authority 
on  the  part  of  the  Executive  Secretary. 

Milestone  Decision  Authorities  (MDAs)  for  other  than  MDAPs  or  MAIS 
acquisition  programs  shall  promulgate  mandatory  procedures  for  those  programs,  imless 
the  CAE  has  already  promulgated  such  procedures.  These  procedures  shall  not  exceed 
the  requirements  for  MDAPs  and  MAIS  acquisition  programs  established  in  this 
Regulation. 
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Unless  otherwise  directed  by  the  MDA,  neither  DoD  Components  nor  program 
managers  (PMs)  shall  update  program  documentation  prepared  in  compliance  with  the 
requirements  of  the  cancelled  DoD  5000.2-R  (in  reissuance  as  DoD  Instruction  5000.2 
(reference  (a))  and  this  Regulation),  as  of  the  date  of  signature  of  this  Regulation,  solely 
to  satisfy  the  requirements  of  this  Regulation. 

The  DAPSG  shall  receive  and  consider  proposals  for,  and,  as  necessary,  generate 
changes  to  this  Regulation.  The  DAPSG  shall  submit  proposed  changes  to  USD(AT&L), 
DOT&E,  and  ASD(C3I)/DoD  CIO,  who  have  the  sole  authority  to  change  this 
Regulation.  All  three  officials  shall  jointly  sign  changes.  The  Director,  Acquisition 
Resoiuces  and  Analysis  shall  maintain  administrative  control  of  this  Regulation  and  shall 
publish  all  signed  changes.  Send  recommended  changes  to: 

Under  Secretary  of  Defense  (Acquisition,  Technology,  and  Logistics) 

ATTN:  Director,  Acquisition  Resources  and  Analysis 
3000  Defense  Pentagon 
Washington,  DC  20301-3000 

DoD  Components  may  obtain  copies  of  this  Regulation  through  their  own 
publication  channels.  Other  Federal  Agencies  and  the  public  may  obtain  copies  from  the 
U.S.  Department  of  Commerce,  National  Technical  Information  Service,  5285  Port  Royal 
Road,  Springfield  VA  22151. 


Under  Secretary  of 
Defense  (Acquisition, 
Technology,  and 
Logistics) 


Acting  Assistant 
Secretary  of  Defense 
(Command,  Control, 
Communications,  and 
Intelligence) 


ctmg  Director, 
Operational  Test  and 
Evaluation 
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AL1.103.  SAR 

Selected  Acquisition  Report 

ALL  104.  SBA 

Simulation-Based  Acquisition 

ALL105.  SBIR 

Small  Business  Innovation  Research 

AL1.106.  SEI 

Software  Engineering  Institute 

ALL107.  SSAA 

System  Security  Authorization  Agreement 

ALL108.  SUPSHIP 

Supervisor  of  Shipbuilding,  Conversion,  and  Repair 

ALL109.  T&E 

Test  and  Evaluation 

ALl.llO.  TEMP 

Test  and  Evaluation  Master  Plan 

ALl.lll.  TOC 

Total  Ownership  Cost 

ALL112.  TRL 

Technology  Readiness  Level 

ALL113.  U.S.C. 

United  States  Code 

ALL114.  UCR 

Unit  Cost  Report 

ALL115.  USD(AT&L) 

Under  Secretary  of  Defense  (Acquisition,  Technology,  and  Logistics) 

ALL116.  USJFCOM 

United  States  Joint  Forces  Command 
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ALl.l  17.  WBS  Work  Breakdown  Structure 

ALl.l  18.  WIPT  Working-Level  Integrated  Product  Team 
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Cl.  CHAPTER  1 
PROGRAM  GOALS 


Cl.l.  GOALS 


Every  acquisition  program  shall  establish  program  goals-thresholds  and  objectives-for  the 
minimum  number  of  cost,  schedule,  and  performance  parameters  that  describe  the  program  over 
its  life  cycle.  The  Department  shall  link  program  goals  to  the  DoD  Strategic  Plan  and  other 
appropriate  subordinate  strategic  plans,  such  as  Component  and  Functional  Strategic  Plans  and 
the  Strategic  Information  Resources  Management  Plan  (44  U.S.C.  3506  (reference  (c))). 

Cl. 2.  THRESHOLDS  AND  OBJECTIVES 

Cl. 2.1.  Each  parameter  shall  have  a  threshold  value  and  an  objective  value. 

Cl. 2. 1.1.  For  performance,  “threshold”  shall  mean  the  minimum  acceptable  value  that, 
in  the  user's  judgment,  is  necessary  to  satisfy  the  need.  For  schedule  and  cost,  "threshold"  shall 
mean  the  maximuTn  allowable  value.  If  performance  threshold  values  are  not  achieved,  program 
performance  may  be  seriously  degraded,  and  the  utility  of  the  system  may  become  questionable. 
If  schedule  threshold  values  are  not  achieved,  the  program  may  no  longer  be  timely.  If  cost 
threshold  values  are  not  achieved,  the  program  may  be  too  costly,  and  the  affordability  of  the 
system  may  become  questionable. 

Cl.2.1.2.  The  objective  value  is  the  value  desired  by  the  user,  and  the  value  the  PM 
tries  to  obtain.  The  objective  value  represents  an  incremental,  operationally  meaningful,  time- 
critical,  and  cost-effective  improvement  to  the  threshold  value  of  each  program  parameter. 

Cl. 2. 1.3.  Program  goals  (parameters  and  values)  may  be  refined  based  on  the  results  of 
the  program’s  preceding  phase(s). 

Cl. 2. 1.4.  For  each  parameter,  if  no  objective  is  specified,  the  threshold  value  shall  also 
serve  as  the  objective  value.  As  a  general  rule,  if  no  threshold  is  specified,  the  performance 
objective  value  shall  also  serve  as  the  performance  threshold  value;  the  schedule  objective  value 
plus  6  months  for  Acquisition  Category  (ACAT)  I  or  3  months  for  ACAT  LA  shall  serve  as  the 
schedule  threshold  value;  or  the  cost  objective  value  plus  10  percent  shall  serve  as  the  cost 
threshold  value.  Despite  these  guidelines,  if  no  threshold  is  specified,  the  PM  may  propose  an 
appropriate  threshold  value  to  optimize  program  trade-space,  subject  to  MDA  and  user  approval. 

Cl. 2. 2.  Maximizing  PM  and  contractor  flexibility  to  make  cost^performance  trade-offs  is 
essential  to  achieving  cost  objectives.  Trade-offs — within  the  objective-to-threshold  “trade 
space” — shall  not  require  higher-level  permission,  but  shall  require  coordination  with  the 
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operational  requirements  developer.  The  operational  requirements  developer  shall  strictly  lumt 
the  number  of  threshold  and  objective  items  in  requirements  documents  and  acquisition  program 
baselines  (APBs).  Performance  threshold  values  shall  represent  true  minimums,  with 
requirements  stated  in  terms  of  capabilities  rather  than  as  technical  solutions  and  specifications. 
Cost  threshold  values  shall  represent  true  maximums.  Cost  objectives  shall  be  used  as  a 
management  tool. 

Cl. 2.3.  When  a  program  has  time-phased  requirements  and  utilizes  an  evolutionary 
acquisition  strategy,  each  block  shall  have  a  set  of  parameters  with  thresholds  and  objectives 
specific  to  the  block. 

Cl  .3.  COST  AS  AN  INDEPENDENT  VARIABLE  ICAIV) 

Cl. 3.1.  In  establishing  realistic  objectives,  the  user  shall  treat  cost  as  a  military  requirement. 
The  acquisition  community,  including  technology  and  logistics,  and  the  requirements  community 
shall  use  the  CATV  process  to  develop  total  ownership  cost  (TOC),  schedule,  and  performance 
thresholds  and  objectives.  They  shall  address  cost  in  the  Operational  Requirements  Document 
(ORD),  and  balance  mission  needs  with  projected  out-year  resources,  taking  into  account 
anticipated  process  improvements  in  both  DoD  and  defense  industries  (5  U.S.C.  306  (reference 
(d))  and  Pub.  L.  104-106  (1996),  Section  5123  (reference  (e))).  CAIV  trades  shall  consider  the 
cost  of  delay  and  the  potential  for  early  operational  capability. 

Cl.3.2.  Upon  ORD  approval  (see  Chairman  of  the  Joint  Chiefs  of  Staff  (CJCS)  Instruction 
3 170.0  IB  (reference  (f))),  the  PM  shall  formulate  a  CATV  plan,  as  part  of  the  acquisition 
strategy,  to  achieve  program  objectives.  Upon  program  initiation,  each  ACAT  I  and  ACAT  lA 
PM  shall  document  TOC  objectives  as  part  of  the  APB.  The  cost  portion  of  the  baseline  shall 
include  the  complete  set  of  TOC  objectives:  research,  development,  test  and  evaluation 
(RDT&E);  procurement;  military  construction;  operating  and  support;  and  disposal  costs;  as  well 
as  other  indirect  costs  attributable  to  the  system,  and  infrastructure  costs  not  directly  attributable 
to  the  system.  The  MDA  shall  re-assess  cost  objectives,  and  progress  towards  achieving  them,  at 
each  subsequent  milestone. 

Cl.3.3.  Cost/Schedule/Performance  Trade-Offs 

Cl. 3.3.1.  The  best  time  to  reduce  TOC  and  program  schedule  is  early  in  the  acquisition 
process.  Continuous  cost/schedule/performance  trade-off  analyses  shall  accomplish  cost  and 
schedule  reductions. 

Cl. 3.3.2.  Cost,  schedule,  and  performance  may  be  traded  within  the  “trade  space” 
between  the  objective  and  the  threshold  without  obtaining  MDA  approval.  Trade-offs  outside 
the  trade  space  (i.e.,  program  parameter  changes)  shall  require  approval  of  both  the  MDA  and  the 
ORD  approval  authority.  Validated  key  performance  parameters  (KPPs)  may  not  be  traded-off 
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without  Requirements  Authority  approval.  The  PM  and  the  operational  requirements  developer 
shall  jointly  coordinate  all  trade-off  decisions. 

C 1 .3 .4.  Management  Incentives 

Cl. 3.4.1.  Incentives  shall  apply  to  both  Government  and  industry,  to  both  individuals 
and  teams,  to  achieve  CAIV  and  schedule  objectives.  Incentives  shall  stress  up-front 
investments  to  minimize  production  cost,  operating  and  support  cost,  and/or  cycle  time,  where 
applicable.  Awards  programs  (both  monetary  and  non-monetary)  and  “shared  savings”  programs 
shall  creatively  encourage  the  generation  of  cost-  and  schedule-saving  ideas  throughout  all 
phases  of  the  life  cycle. 

Cl. 3. 4.2.  The  PM,  via  the  Contracting  Officer,  shall  structure  Requests  for  Proposal 
(RFPs)  and  resulting  contracts  to  incentivize  the  contractor  to  meet  or  beat  program  objectives. 
Whenever  applicable,  risk  reduction  through  use  of  mature  processes  shall  be  a  significant  factor 
in  source  selection.  RFPs  and  resulting  contracts  shall  include  a  strict  minimum  niunber  of 
critical  performance  criteria  (i.e.,  threshold  and  objective  requirements)  to  allow  industry 
maximiim  flexibility  in  meeting  overall  program  objectives.  The  source  selection  criteria 
communicated  to  industry  shall  reflect  the  importance  of  developing  a  system  that  can  achieve 
stated  production  and  TOC  objectives  within  schedule  and  performance  objectives. 

Cl. 3.4.3.  For  industry,  competition  to  win  business,  along  with  attendant  business 
profit,  is  by  far  the  most  powerful  incentive.  Therefore,  the  PM  shall  maintain  competition  as 
long  as  practicable  in  all  acquisition  programs. 

Cl. 4.  ACQUISITION  PROGRAM  BASELINE  (APBI 

Cl.4.1 .  Every  acquisition  program  shall  establish  an  APB  beginning  at  program  initiation. 
The  PM  shall  base  the  APB  on  users'  performance  requirements,  schedule  requirements,  and 
estimate  of  total  program  cost.  Performance  shall  include  interoperability,  supportability  and,  as 
applicable,  environmental  requirements.  The  department  shall  not  obligate  funds  for  ACAT I  or 
ACAT  LA  programs  beyond  Milestone  B  until  the  MDA  approves  the  APB,  unless  the 
USD(AT&L)  (for  ACAT  I)  or  the  ASD(C3I)  (for  ACAT  lA)  specifically  approves  the  obligation 
(10  U.S.C.  2435(b)  (reference  (g))).  The  APB  satisfies  requirements  derived  from  both  10 
U.S.C.  2220(a)(1)  (reference  (h))  and  reference  (g). 

C 1 .4.2 .  Preparation  and  Approval 

Cl. 4.2.1.  The  PM,  in  coordination  with  the  user,  shall  prepare  the  APB  at  program 
initiation;  and  shall  revise  the  APB  subsequent  to  milestone  reviews,  program  restructunngs,  or 
unrecoverable  program  deviations.  The  Program  Executive  Officer  (PEO)  and  the  CAE,  as 
appropriate,  shall  concur  in  the  APB.  For  ACAT  I  and  lA  programs,  the  MDA  shall  retain 
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approval  authority,  but  shall  not  approve  the  APB  without  coordination  of  the  Under  Secretary  of 
Defense  (Comptroller)  (10  U.S.C.  2220(a)(2)  (reference  (h)))  and  the  Requirements  Authority. 

Cl. 4.2.2.  The  APB  is  part  of  the  Consolidated  Acquisition  Reporting  System  (CARS). 
The  PM  shall  use  CARS  to  prepare  the  APB  (see  Appendix  1). 

Cl. 4.3.  APB  Content.  APB  parameter  values  shall  represent  the  program  as  it  is  expected 
to  be  produced  or  deployed.  In  the  case  of  delivering  systems  under  an  evolutionary  acquisition 
strategy,  the  APB  shall  include  parameters  for  the  next  block  and,  if  known,  for  follow-on 
blocks.  The  APB  shall  contain  only  those  parameters  that,  if  thresholds  are  not  met,  will  require 
the  MDA  to  reevaluate  the  program  and  consider  alternative  program  concepts  or  design 
approaches.  The  following  considerations  apply: 

Cl. 4.3.1.  Performance 

Cl.4.3.1.1.  The  total  number  of  performance  parameters  shall  be  the  mmimum 
munber  needed  to  characterize  the  major  drivers  of  operational  performance,  supportability,  and 
interoperability  (10  U.S.C.  2435  (reference  (g))).  This  minimum  number  shall  include  the  KPPs 
identified  in  the  ORD.  The  value  of  a  threshold  or  objective  in  the  APB  shall  not  differ  from  the 
value  for  a  like  threshold  or  objective  in  the  ORD,  and  their  definitions  shall  be  consistent.  The 
MDA  may  add  additional  performance  parameters  not  validated  by  the  Joint  Requirements 
Oversight  Council  (JROC). 

Cl. 4.3. 1.2.  The  number  and  specificity  of  performance  parameters  increase  with 
time.  Early  in  a  program  die  PM  shall  use  a  minimum  number  of  broadly  defined,  operational- 
level,  measures  of  effectiveness  (MOEs)  or  measures  of  performance  (MOPs)  to  describe  needed 
capabilities.  As  program,  system-level  requirements  become  better  defined,  the  PM  may 
designate  a  limited  number  of  additional,  specific,  program  parameters,  as  necessary. 

Cl.4.3.2.  Schedule.  Schedule  parameters  shall  minimally  include  dates  for  program 
initiation,  major  decision  points,  and  the  attainment  of  initial  operating  capability  (IOC).  The 
PM  may  propose,  for  MDA  approval,  other,  specific,  critical,  system  events,  as  necessary.  In 
accordance  with  10  U.S.C.  181  (reference  (i)),  the  JROC  shall  evaluate  program  schedule 
criteria,  including  critical  schedule  dates,  for  ACAT I  programs. 

Cl. 4.3.3.  Cost 

Cl. 4.3. 3.1.  Cost  parameters  shall  identify  TOC  (broken-out  into  direct  costs: 
research,  development,  test,  and  evaluation  costs,  procurement  costs,  military  construction  costs, 
operating  and  support  costs  (to  include  environmental,  safety,  and  occupational  health 
compliance  costs),  and  the  costs  of  acquisition  items  procured  with  operations  and  maintenance 
funds,  if  applicable;  indirect  costs  attributable  to  the  systems;  and  infrastructure  costs  not  directly 
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attributable  to  the  system);  total  quantity  (including  both  fully  configured  development  and 
production  units)  costs;  average  procurement  unit  cost  (defined  as  the  total  prociuement  cost 
divided  by  total  procurement  quantity);  program  acquisition  unit  cost  (defined  as  the  total  of  all 
acquisition  related  appropriations  divided  by  the  total  quantity  of  fully  configured  end  items); 
and  other  cost  objectives  designated  by  the  MDA.  For  reporting  purposes,  the  PM  shall  use  life- 
cycle  costs  as  defined  in  DoD  5000.4-M  (reference  (j)).  The  PM  shall  present  cost  figures  in 
base  year  dollars. 

Cl.4.3.3.2.  Cost  figures  shall  reflect  realistic  estimates  of  the  total  program, 
including  a  thorough  assessment  of  risk.  As  the  program  progresses,  the  PM  shall  refine 
procurement  costs  based  on  contractor  actual  (return)  costs  from  component  advanced 
development,  system  integration,  and  system  demonstration,  as  available,  and  from  low-rate 
initial  production  (LRIP).  The  PM  shall  include  the  refined  estimate  in  the  next  required 
submittal  of  the  APB.  Budgeted  amounts  shall  not  exceed  the  total  cost  thresholds  in  the  APB. 
For  ACAT  lA  programs,  ACAT I  cost  parameters  shall  apply  with  the  addition  of  military  pay 
and  the  cost  of  acquisition  items  procured  with  Defense  Working  Capital  Funds.  The  JROC 
shall  evaluate  program  cost  criteria  for  ACAT  I  programs  (10  U.S.C.  181  (reference  (i))). 

Cl. 4.4.  Evolutionary  Acquisition 

Cl. 4.4.1.  The  APB  for  a  program  using  an  evolutionary  acquisition  strategy  shall 
contain  separate  entries  for  each  block.  The  APB  shall  be  consistent  with  the  ORD,  as  follows: 

Cl. 4.4. 1.1.  If  a  single,  time-phased  ORD  defines  multiple  capability  levels,  the 
APB  shall  contain  multiple  sets  of  parameter  values,  each  defining  a  block. 

Cl. 4.4. 1.2.  If  the  users  incrementally  update  and  validate  a  single  ORD  to  define 
increasing  capability,  the  PM  shall  incrementally  update  APB  performance  parameter  values. 

Cl.4.4.1.3.  If  the  users  submit  multiple  ORDs,  the  PM  shall  prepare  separate 
APBs,  each  defining  a  block. 

Cl. 4.4. 1.4.  If  users  submit  an  ORD  defining  objective  capability  and  initially 
acceptable  capability,  without  defining  intermediate  capability  levels,  the  PM  shall  prepare  an 
APB  with  a  complete  set  of  parameter  values  for  block  1  and  as  many  parameter  values  of 
objective  capability  as  are  provided  in  the  ORD. 

Cl. 4.4.2.  The  details  required  for  each  block  in  an  evolutionary  acquisition  program 
shall  adhere  to  the  guidance  provided  in  Cl. 4.3. 
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Cl. 4.5.  Program  Deviations 

C 1 .4.5. 1 .  PMs  shall  maintain  a  current  DoD  Component  and/or  PM  estimate  of  the 
parameters  of  the  program  being  actually  executed.  The  current  estimate  shall  reflect  the  current 
President's  Budget,  adjusted  for  fact-of-life  changes  (i.e.,  already  happened  or  unavoidable). 

Cl  .4.5.2.  A  program  deviation  occurs  when  the  PM  has  reason  to  believe  that  the 
current  estimate  for  the  program  indicates  that  a  performance,  schedule,  or  cost  threshold  value 
will  not  be  achieved.  The  PM  shall  immediately  notify  the  MDA  when  a  deviation  occurs. 
Within  30  days  of  the  occurrence  of  the  program  deviation,  the  PM  shall  notify  the  MDA  of  the 
reason  for  the  program  deviation  and  the  actions  that  need  to  be  taken  to  bring  the  program  back 
within  the  baseline  parameters  (if  this  information  was  not  included  with  the  original 
notification).  Within  90  days  of  the  occurrence  of  the  program  deviation,  one  of  the  following 
shall  have  occurred:  the  program  shall  be  back  within  APB  parameters;  a  new  APB  (changing 
only  those  parameters  that  breached)  shall  have  been  approved;  or  an  Overarching  Integrated 
Product  Team  (OIPT)-level  program  review  shall  have  been  conducted  for  AC  AT  ID  or  AC  AT 
LAM  programs  to  review  the  PM’s  proposed  baseline  revisions  and  make  recommendations  to 
the  MDA. 

Cl.4.5.3.  For  ACAT I  programs,  if  one  of  these  three  actions  has  not  occurred  within 
90  days  of  the  program  deviation,  the  USD(AT&L)  for  ACAT  ID  programs,  the  ASD(C3I)  for 
ACAT  lAM  programs,  or  the  CAE,  for  ACAT  IC  and/or  ACAT  lAC  programs,  shall  require  a 
formal  program  review  to  determine  program  status. 

Cl.4.6.  Information  Technology  (IT)  Program  Deviations.  The  CAE  shall  identify,  in 
DoD’s  Strategic  Information  Resource  Management  Plan,  major  information  technology 
acquisition  programs  that  have  significantly  deviated  from  the  cost,  performance,  or  schedule 
goals  established  for  the  program  (40  U.S.C.  1427  (reference  (k))). 

Cl.4.7.  Clinger-Cohen  Act  Compliance.  DoD  Instruction  5000.2,  (reference  (a)) 
establishes  minimum  planning  requirements  for  the  acquisition  of  information  technology 
systems,  as  required  by  Section  81 1  of  the  FY  01  Authorizations  Act  (reference  (1))  (see 
reference  (a),  sections  4.7.3. 1.5  and  4.7.3 .2. 3.2.). 
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C2.  CHAPTER  2 
ACQUISITION  STRATEGY 

C2. 1  ■  GENERAL  CONSIDERATIONS  FOR  THE  ACQUISITION  STRATEGY 

C2. 1 . 1 .  Each  PM  shall  develop  and  document  an  acquisition  strategy  to  guide  program 
execution  from  initiation  through  reprocurement  of  systems,  subsystems,  components,  spares, 
and  services  beyond  the  initial  production  contract  award  and  during  post-production  support. 
The  acquisition  strategy  shall  evolve  through  an  iterative  process  and  become  increasingly  more 
definitive  in  describing  the  relationship  of  the  essential  elements  of  a  program.  A  primary  goal 
of  the  strategy  shall  be  to  minimize  the  time  and  cost  it  takes,  consistent  with  common  sense  and 
sovmd  business  practices,  to  satisfy  identified,  validated  needs,  and  to  maximize  affordability 
throughout  a  program’s  useful  life  cycle. 

C2.1.2.  In  developing  the  acquisition  strategy,  the  PM  shall  consider  all  policy  and 
guidance  in  this  chapter.  In  documenting  the  acquisition  strategy,  the  PM  shall  provide  a 
complete  picture  of  the  strategy  for  the  decision  makers  who  will  be  asked  to  coordinate  on  or 
approve  the  strategy  document.  The  PM  shall  ensure  the  document  satisfies  the  requirements  in 
this  chapter  for  the  acquisition  strategy  to  identify,  address,  describe,  summarize,  or  otherwise 
document  specific,  major  aspects  or  issues  of  the  program  or  strategy. 

C2.1.3.  When  to  Prepare  and  Update  the  Acquisition  Strategy.  The  PM  shall  develop  the 
acquisition  strategy  in  preparation  for  program  initiation,  prior  to  the  program  initiation  decision, 
and  update  it  prior  to  all  major  program  decision  points  or  whenever  the  approved  acquisition 
strategy  changes  or  as  the  system  approach  and  program  elements  become  better  defined.  The 
PM  shall  engage  the  Working-Level  Integrated  Product  Team  (WIPT)  and  Operational  Test 
Agency  (OTA)  in  the  development  of  the  acquisition  strategy,  and  obtain  concurrence  of  the 
PEO  and  CAE,  as  appropriate. 

C2.1.4.  Approval  of  Acquisition  Strategies.  The  MDA  shall  approve  the  acquisition 
strategy  prior  to  the  release  of  the  formal  solicitation.  Approval  shall  usually  precede  each 
decision  point,  except  at  program  initiation,  when  the  acquisition  strategy  shall  usually  be 
approved  as  part  of  the  milestone  decision  review. 

C2.2.  REQUIREMENTS 

C2.2. 1 .  The  acquisition  strategy  shall  provide  a  summary  description  of  the  requirement  the 
acquisition  is  intended  to  satisfy.  The  summary  shall  highlight  aspects  of  the  requirement  (1) 
driven  by  family-of-systems  or  mission  area  requirements  for  interoperability,  and  (2)  that  reflect 
dependency  on  planned  capability  being  achieved  by  other  programs.  The  summary  shall  also 
state  whether  the  requirement  is  structured  to  achieve  full  capability  in  time-phased  increments 
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or  in  a  single  step.  For  time-phased  requirements,  define  the  block  about  to  be  imdertaken,  as 
well  as  subsequent  blocks. 

C2.2.2.  Approved  Source  Docxunents.  The  acquisition  strategy  shall  identify  approved 
source  documents  constituting  the  authoritative  definition  of  the  requirement.  Such  documents 
include  the  ORD,  Capstone  Requirements  Document  (CRD),  and  APB. 

C2.2.3.  Status  of  In-Process  Source  Documents.  The  acquisition  strategy  shall  describe  the 
status  of  source  documents  as  of  a  specified  date.  Identify  any  significant  aspects  of  the 
requirement  that  are  unsettled,  and  the  impact  this  uncertainty  has  on  the  acquisition  strategy. 

The  acquisition  strategy  shall  be  flexible  enough  to  accommodate  the  requirements  decisions 
ultimately  made,  either  through  providing  alternative  strategies  when  potential  outcomes  are 
limited  and  known,  or  through  providing  for  a  strategy  update. 

C2.3.  PROGRAM  STRUCTURE 

C2.3.1.  The  acquisition  strategy  shall  prescribe  accomplishments  for  each  acquisition  phase, 
and  shall  identify  the  critical  events  that  govern  program  management.  The  event-driven 
acquisition  strategy  shall  explicitly  link  program  decisions  to  demonstrated  accomplishments  in 
development,  testing,  initial  production,  life-cycle  support,  and  the  availability  of  capabilities,  to 
be  provided  by  other  programs,  on  which  this  program  depends.  The  acquisition  strategy  shall 
specifically  address  the  benefits  and  risks  associated  with  reducing  lead-time  through 
concxirrency  and  the  risk  mitigation  and  tests  planned  if  concurrent  development  is  used.  Events 
set  forth  in  contracts  shall  support  the  appropriate  exit  criteria  for  the  phase  or  intermediate 
development  events,  established  for  the  acquisition  strategy. 

C2.3.2.  The  acquisition  strategy  shall  define  the  relationship  among  acquisition  phases, 
work  efforts,  decision  points,  solicitations,  contract  awards,  systems  engineering  design  reviews, 
contract  deliveries,  test  and  evaluation  (T&E)  activities,  production  lots,  and  operational 
deployment  objectives.  The  PM  shall  depict  these  relationships  in  a  summary  diagram  as  part  of 
the  strategy. 

C2.4.  ACQUISITION  APPROACH 

C2.4.1.  The  acquisition  strategy  shall  identify  the  approach  the  program  will  use  to  achieve 
full  capability;  an  evolutionary  approach  or  a  single  step  approach.  Consistent  with  DoD 
Instruction  5000.2,  paragraph  4.7.3.2.3.3  (reference  (a)),  the  acquisition  strategy  shall  provide 
the  rationale  for  choosing  the  approach.  If  an  evolutionary  approach  is  being  used,  the 
acquisition  strategy  program  structure  shall  describe  Block  1  (the  initial  deployment  capability), 
and  how  it  will  be  funded,  developed,  tested,  produced,  and  supported,  and  the  approach  to 
treatment  of  subsequent  blocks. 
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C2.4.2.  If  the  ORD  includes  a  firm  definition  of  requirements  to  be  satisfied  by  each  block, 
the  acquisition  strategy  shall  define  each  block  of  capability  and  how  it  will  be  funded, 
developed,  tested,  produced,  and  operationally  supported. 

C2.4.3.  If  the  ORD  does  not  allocate  to  specific  subsequent  blocks  the  remaining 
requirements  that  must  be  met  to  achieve  full  capability,  the  acquisition  strategy  shall  define  the 
full  capability  the  acquisition  is  intended  to  satisfy;  the  funding  and  schedule  planned  to  achieve 
the  full  capability  to  the  extent  it  can  be  described;  and  the  management  approach  to  be  used  to 
define  the  requirements  for  each  subsequent  block  and  the  acquisition  strategy  applicable  to  each 
block,  including  whether  end  items  delivered  under  earlier  blocks  will  be  retrofitted  with  later 
block  improvements. 

C2.5.  RISK 

The  acquisition  strategy  shall  address  risk  management.  The  PM  shall  identify  the  risk  areas  of 
the  program  and  integrate  risk  management  within  overall  program  management.  The  strategy 
shall  explain  how  the  risk  management  effort  shall  reduce  system-level  risk  to  acceptable  levels 
by  the  interim  progress  review  preceding  system  demonstration  and  by  Milestone  C. 

C2.6.  PROGRAM  MANAGEMENT 

The  acquisition  strategy  shall  be  sufficiently  detailed  to  establish  a  management  approach  to 
achieve  program  goals. 

C2.6.1.  Resources.  The  acquisition  strategy  shall  describe  the  planned  funding  approach 
including  transition  funding  and  funding  under  an  evolutionary  acquisition  strategy.  It  shall 
detail  advance  procurement  and  staffing,  if  appropriate. 

C2.6.1.1.  Advance  Procurement* 

C2.6. 1.1.1.  In  accordance  with  DoD  Regulation  7000. 14-R  (reference  (m)), 
procurement  of  end  items  shall  be  fully  funded,  i.e.,  the  cost  of  the  end  items  to  be  bought  in  any 
fiscal  year  shall  be  completely  included  in  that  year’s  budget  request.  However,  there  are 
occasions  when  it  is  appropriate  that  some  components,  parts,  material,  or  effort  be  procured  in 
advance  of  the  end  item  buy,  as  authorized,  to  preclude  serious  and  costly  fluctuation  in  program 
continuity  or  when  items  have  significantly  longer  lead  times  than  other  components,  parts,  and 
material  of  the  same  end  item.  In  these  instances,  the  long  lead-time  material  or  effort  may  be 
procured  with  advance  procurement  fimds,  but  only  in  sufficient  quantity  to  support  the  next 
fiscal  year  quantity  end-item  buy  (except  for  economic  order  quantity  procurement  of  material  to 
support  a  multi-year  procurement),  and  only  to  buy  those  long-lead  items  necessary  to  maintain 
critical  skills  and  proficiencies  that  would  otherwise  have  to  be  reconstituted  at  significantly 
greater  net  cost  to  the  Government.  When  advance  procurement  is  part  of  a  program,  the  cost  of 
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components,  material,  parts,  and  effort  budgeted  for  advance  procurement  shall  be  relatively  low 
compared  to  the  remaining  portion  of  the  cost  of  the  end  item.  Because  such  use  of  advance 
procurement  limits  the  MDA’s  flexibility,  this  acquisition  technique  shall  be  used  only  when  the 
cost  benefits  are  significant  and  only  with  approval  of  the  MDA. 

C2.6.1.1.2.  Exit  criteria  for  awarding  of  the  initial  long  lead-time  items  contract 
and/or  for  awarding  of  individual  follow-on  long  lead-time  lots  shall  be  established  as  an  integral 
part  of  the  milestone  approval  process.  These  approved  exit  criteria  shall  be  satisfied  before  any 
advance  procurement  funding  may  be  released.  The  initiation  of  advance  procurement  in  support 
of  long  lead  material  shall  use  a  separate  contract. 

*  Not  applicable  to  ACAT  lA  programs. 

C2.6.1.2.  Program  Office  Staffing  and  Support  Contractors.  The  acquisition  strategy 
shall  briefly  describe  the  program  office  personnel  and  support  contractor  resources  available  to 
support  the  PM.  It  shall  state  whether  resource  limitations  prevent  the  PM  from  pursuing  a 
strategy  or  approach  considered  beneficial.  It  shall  identify  those  strategies  or  approaches  (e.g., 
award  fee  contract;  or  component  breakout,  with  the  government  contracting  for  the  component, 
and  furnishing  it  to  the  prime  contractor)  and  estimate  the  additional  resources  needed  to 
implement  them. 

C2.6.2.  Information  Sharing  and  DoD  Oversight.  DoD  oversight  activities  (i.e.,  contract 
management  offices,  contracting  offices,  technical  activities,  and  program  management  offices) 
shall  consider  all  relevant  and  credible  information  that  might  mitigate  risk  and  reduce  the  need 
for  DoD  oversight  before  defining  and  applying  direct  DoD  oversight  of  contractor  operations. 
DoD  buying  and  technical  activities  shall  provide  to  the  Director,  Defense  Contract  Management 
Agency  (DCMA),  copies  of  reviews  of  contractor  operations  and  other  documents  assessing  or 
rating  contractor  performance  or  operations  unless  disclosure  of  this  information  would 
compromise  national  security.  The  Director,  DCMA,  shall  make  information  relating  to  audits, 
reviews,  or  ratings  of  contractor  operations,  systems,  or  performance  accessible  to  DoD  buying 
and  technical  activities. 

C2.6.3.  Integrated  Digital  Environment  (IDE) 

C2.6.3.1.  DoD  policy  requires  the  maximum  use  of  digital  operations  throughout 
acquisition  and  the  entire  system  life  cycle.  The  acquisition  strategy  shall  summarize  how  the 
PM  will  establish  a  cost-effective  data  management  system  and  appropriate  digital  environment 
that  shall  allow  every  activity  involved  with  the  program,  throughout  its  total  life-cycle,  to 
digitally  exchange  data.  The  IDE  shall  keep  pace  with  evolving  automation  technologies,  and 
shall  use  existing  infrastructure  (e.g.,  Internet)  to  the  maximum  extent  practicable.  The 
following  shall  also  apply: 


30 


CHAPTER  2 


DoD  5000.2-R.  June  2001 


C2.6.3. 1 . 1 .  PMs  shall  establish  a  data  management  system  and  appropriate  digital 
environment  to  allow  every  activity  involved  with  the  program  to  cost  effectively  create,  store, 
access,  manipulate,  and/or  exchange  data  digitally.  The  IDE  shall,  at  a  minimum,  meet  the  data 
management  needs  of  the  support  strategy,  system  engineering  process,  modeling  and  simulation 
activities,  T&E  strategy,  and  periodic  reporting  requirements.  The  design  shall  allow  ready 
access  to  anyone  with  a  need-to-know  (as  determined  by  the  PM),  a  technologically  “current” 
personal  computer,  and  Internet  access  through  a  Commercial,  Off-the-Shelf  (COTS)  browser. 

C2. 6.3. 1.2.  Solicitations  shall  require  specific  proposals  for  an  IDE  solution  to 
support  acquisition  and  operational  support  activities.  Unless  analysis  verifies  prohibitive  cost  or 
time  delays  or  a  potential  compromise  of  national  security,  new  contracts  shall  require  the 
contractor  to  provide  on-line  access  to  programmatic  and  technical  data.  Contracts  shall  give 
preference  to  on-line  access  (versus  data  exchange)  through  a  contractor  information  service  or 
an  existing  IT  infrastructure.  Contracts  shall  specify  the  required  functionality  and  data 
standards.  The  data  formats  of  independent  standards-setting  organizations  shall  take  precedence 
over  all  other  formats.  The  issue  of  data  formats  and  transaction  sets  shall  be  independent  of  the 
method  of  access  or  delivery. 

C2.6.3.1.3.  Industry  partners  have  been  strongly  encouraged  to  develop  and 
implement  IDE  solutions  that  best  meet  their  preferred  business  models.  Consequently,  program 
office  IDE  shall  take  maximum  advantage  of  and  have  minimum  impact  on  industry  solutions. 

C2.6.3.2.  At  milestone  and  other  appropriate  decision  points  and  program  reviews,  the 
PM  shall  address  the  status  and  effectiveness  of  the  IDE. 

C2.6.4.  Technical  Representatives  at  Contractor  Facilities.  PMs  shall  make  maximum  use 
of  DCMA  personnel  at  contractor  facilities.  PMs  and  DCMA  Contract  Management  Offices 
shall  jointly  develop  and  approve  program  support  plans  for  all  AC  AT  I  program  contracts  to 
ensure  agreement  on  contract  oversight  needs  and  perspectives.  The  PM  shall  only  assign 
technical  representatives  to  a  contractor’s  facility,  as  necessary,  and  as  agreed  to  by  the  Director, 
DCMA.  A  Memorandum  of  Agreement  shall  specify  the  duties  of  the  technical  representative 
and  establish  coordination  and  communication  activities.  Technical  representatives  shall  not 
perform  contract  administration  duties  as  outlined  in  Federal  Acquisition  Regulation  (FAR) 
Section  42.302(a)  (reference  (n)). 

C2.6.5.  Government  Property  in  the  Possession  of  Contractors  (GPPC) 

C2.6.5.1.  All  PMs  who  own  or  use  GPPC  shall  have  a  process  to  ensure  continued 
management  emphasis  on  reducing  GPPC  and  prevent  any  unnecessary  additions  of  GPPC.  PMs 
shall  examine  their  management  of  active  and  idle  GPPC  and  special  tooling  or  special  test 
equipment  that  the  Government  may  require  the  contractor  to  deliver,  to  ensure  that  decisions 
about  retention,  disposition,  and  requiring  delivery  are  informed  and  timely.  The  PM  shall 
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assign  responsibility  within  the  program  office  and  detail  actions,  reviews,  and  reports  to  be  used 
to  manage  and  dispose  of  GPPC  used  on  the  program.  This  also  includes  government  property 
that  is  not  “owned”  by  the  PM,  but  is  allowed  to  be  used  on  the  program.  The  acquisition 
strategy  shall  address  these  planned  actions. 

C2.6.5.2.  Government  property  may  be  furnished  to  contractors  only  under  the  criteria, 
restriction,  and  documentation  requirements  addressed  in  FAR  45.3  (reference  (o)). 

C2.6.5.3.  The  PM  shall  periodically  review  and  continuously  maintain  oversight  of 
GPPC  to  assure  that  property  no  longer  needed  for  current  contract  performance  or  future  needs 
is  disposed  of  promptly  or  reutilized  in  accordance  with  applicable  laws  and  regulations.  The 
PM  shall  insure  that  Government  property,  left  with  the  contractor  but  not  needed  for 
performance  of  the  contract,  is  stored  under  a  funded  storage  agreement.  Individual  decisions 
regarding  particular  property  shall  be  documented  in  the  contract  file. 

C2.6.6.  Tailoring  and  Streamlining  Plans 

C2.6.6.1.  The  PM  shall  tailor  all  acquisition  strategies  to  contain  only  those  process 
requirements  that  are  essential  and  cost-effective.  The  following  policy  applies: 

C2.6.6.1.1.  Acquisition  process  requirements  shall  be  tailored  to  meet  the  specific 
needs  of  individual  programs. 

C2.6.6. 1.2.  Acquisition  strategies  shall  incorporate  a  performance-based  business 
environment  (PBBE)  to  enable  government  customers  and  contractor  suppliers  to  jointly 
capitalize  on  commercial  process  efficiencies  to  improve  acquisition  and  sustainment  processes. 

C2.6.6.1.3.  Management  data  requirements  shall  be  limited  to  those  essential  for 
effective  control. 

C2.6.6.2.  Request  for  Relief  or  Exemption.  The  acquisition  strategy  shall  identify 
acquisition  process  requirements  that  fail  to  add  value,  are  not  essential,  or  are  not  cost  effective, 
and  shall  indicate  whether  relief  or  exemption  from  those  requirements  is  being  sought  or  has 
already  been  obtained.  The  acquisition  strategy  shall  include  the  status  of  pending  requests. 

C2.6.6.3.  Applying  Best  Practices.  In  tailoring  an  acquisition  strategy,  the  PM  shall 
address  management  constraints  imposed  on  the  contractor(s).  PMs  shall  avoid  imposing 
government-unique  restrictions  that  significantly  increase  industry  compliance  costs  or 
unnecessarily  deter  qualified  contractors,  including  non-traditional  defense  firms  from 
proposing.  Examples  of  practices  that  support  the  implementation  of  these  policies  include 
Integrated  Product  and  Process  Development  (IPPD);  performance-based  specifications; 
management  goals;  reporting  and  incentives;  an  open  systems  approach  that  emphasizes 
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commercially  supported  practices,  products,  performance  specifications,  and  performance-based 
standards;  replacement  of  government-unique  management  and  manufacturing  systems  with 
common,  facility-wide  systems;  technology  insertion  for  continuous  affordability  improvement 
throughout  the  product  life  cycle;  realistic  cost  estimates  and  cost  objectives;  adequate 
competition  among  viable  offerors;  best  value  evaluation  and  award  criteria;  the  use  of  past 
performance  in  source  selection;  results  of  software  capability  evaluations;  government-industry 
partnerships,  consistent  with  contract  documents;  and  the  use  of  pilot  programs  to  explore 
innovative  practices.  The  MDA  shall  review  best  practices  at  each  decision  point. 

C2.6.7.  Planning  for  Simulation-Based  Acquisition  (SBA)  and  Modeling  and  Simulation 
(M&S).  SBA  is  the  robust  and  interactive  use  of  M&S  throughout  the  product  life  cycle.  The 
PM  shall  use  SBA  and  M&S  during  system  design,  system  T&E,  and  system  modification  and 
upgrade.  In  collaboration  with  industry  and  operational  users,  PMs  shall  integrate  SBA/M&S 
into  program  planning  activities;  shall  plan  for  life-cycle  application,  support,  documentation, 
and  reuse  of  models  and  simulations;  and  shall  integrate  SBA/M&S  across  the  functional 
disciplines.  The  following  SBA/M&S  guidelines  apply: 

C2.6.7.1.  PMs  shall  plan  for  SBA/M&S  and  make  necessary  investments  early  in  the 
acquisition  life  cycle. 

C2.6.7.2.  The  PM  shall  use  verified,  validated,  and  accredited  models  and  simulations, 
and  ensure  credible  applicability  for  each  proposed  use. 

C2.6.7.3.  The  PM  shall  use  data  fi'om  system  testing  during  development  to  validate  the 
use  of  M&S. 

C2.6.7.4.  SBA/M&S  shall  support  efficient  test  planning;  pre-test  results  prediction; 
validation  of  system  interoperability;  and  shall  supplement  design  qualification,  actual  T&E, 
manufacturing,  and  operational  support. 

C2. 6.7.5.  The  PM  shall  involve  the  OTA  in  SBA/M&S  planning  to  support  both 
developmental  test  and  operational  test  objectives. 

C2.6.7.6.  DIA  shall  review  and  validate  threat-related  elements  in  SBA/M&S  planning. 

C2.6.7.7.  The  PM  shall  describe,  in  the  acquisition  strategy,  the  plaimed 
implementation  of  SBA/M&S  throughout  program  development,  including  during  engineering, 
manufacturing,  and  design  trade  studies;  and  in  developmental,  operational  and  live  fire  testing 
applications. 
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C2.6.8.  Independent  Expert  Review  of  ACAT  I-III  Software  Intensive  Programs.  The 
acquisition  strategy  shall  describe  the  planned  use  of  independent  expert  reviews  for  all  ACAT  I 
through  ACAT  III  software-intensive  programs. 

C2.7.  DESIGN  CONSIDERATIONS  AFFECTING  THE  ACQUISITION  STRATEGY 

The  acquisition  strategy  shall  describe  how  the  PM’s  technical  management  approach,  developed 
in  accordance  with  Chapter  5,  will  support  the  acquisition  decision  process  and  performance- 
based  business  strategy  described  in  the  acquisition  strategy.  The  acquisition  strategy  shall 
address  how  the  design  and  development  effort  will  generate  appropriate  performance  measures 
for  program  control  and  MDA-level  management  insight.  This  discussion  shall  include,  but  not 
necessarily  be  limited  to,  the  issues  in  the  following  paragraphs. 

C2.7.1.  Open  Systems.  PMs  shall  apply  the  open  systems  approach  as  an  integrated 
business  and  technical  strategy  upon  defining  user  needs.  PMs  shall  assess  the  feasibility  of 
using  widely-supported  commercial  interface  standards  in  developing  systems.  The  open 
systems  approach  shall  be  an  integral  part  of  the  overall  acquisition  strategy  to  enable  rapid 
acquisition  with  demonstrated  technology,  evolutionary  and  conventional  development, 
interoperability,  life-cycle  supportability,  and  incremental  system  upgradability  without  major 
redesign  during  initial  procurement  and  reprocurement  of  systems,  subsystems,  components, 
spares,  and  services,  and  during  post-production  support.  It  shall  enable  continued  access  to 
cutting  edge  technologies  and  products  and  prevent  being  locked  in  to  proprietary  technology. 
PMs  shall  document  their  approach  for  using  open  systems  and  include  a  summary  of  their 
approach  as  part  of  their  overall  acquisition  strategy. 

C2.7.2.  Interoperability.  All  acquired  systems  shall  be  interoperable  with  other  U.S.  and 
allied  defense  systems,  as  defined  in  the  requirements  and  interoperability  documents.  The  PM 
shall  describe  the  treatment  of  interoperability  requirements.  If  the  acquisition  strategy  involves 
successive  blocks  satisfying  time-phased  requirements,  this  description  shall  address  each  block, 
as  well  as  the  transitions  from  block  to  block.  This  description  shall  identify  enabling  system 
engineering  efforts  such  as  network  analysis,  interface  control  efforts,  open  systems,  data 
management,  and  standardization.  It  shall  also  identify  related  requirements  or  constraints  (e.g., 
treaties  or  international  standardization  agreements)  that  impact  interoperability  requirements 
(e.g.,  standards  required  by  the  DoD  Joint  Technical  Architecture  (JTA)  or  the  systems,  forces, 
units,  etc.  for  which  interoperability  is  at,  or  could  be  at  issue),  and  any  waivers  or  deviations 
that  have  been  obtained  or  are  anticipated  being  sought.  The  acquisition  strategy  shall  reflect  full 
compliance  with  the  interoperability  policies  in  paragraph  C5.2.3.5.11.  and,  for  IT,  including 
National  Secmity  Systems  (NSS),  section  C6.3.  The  MDA  shall  adjudicate  interoperability 
issues. 


C2.7.2.1.  Information  Interoperability.  The  PM  shall  identify  and  assess  the  techmcal, 
schedule,  cost,  and  funding  critical  path  issues  (i.e.,  issues  that  could  impact  the  PM's  ability  to 
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execute  the  acquisition  strategy)  related  to  interoperability  for  the  PM’s  acquisition  program. 

The  PM  shall  identify  the  critical  path  issues  in  other  program(s)  (i.e.,  system(s))  that  will 
exchange  information  with  the  PM’s  delivered  system,  and  assess  the  potential  impact  of  these 
issues  on  the  PM’s  program. 

C2.7.2.2.  Other-than  Information  Interoperability.  The  PM  shall  identify  and  assess  the 
technical,  schedule,  cost,  and  funding  critical  path  issues  (see  paragraph  C2.7.2.1.)  related  to 
interoperability  for  the  PM’s  acquisition  program.  The  PM  shall  identify  the  critical  path  issues 
in  other  program(s)  (i.e.,  system(s))  that  will  interoperate  with  or  otherwise  materially  interact 
with  the  PM’s  delivered  system  (e.g.,  fuel  formulation  and  delivery  systems,  mechanical 
connectors,  armament,  or  power  characteristics). 

C2.7.3.  IT  Supportability.  The  acquisition  strategy  shall  summarize  the  IT,  including  NSS, 
infrastructure  and  support  considerations  identified  in  the  ORD  and  described  in  the  Command, 
Control,  Communications,  Computers,  and  Intelligence  Support  Plan  (C4ISP)  (see  Appendix  5). 
If  IT,  including  NSS,  infrastructure  enhancements  are  required  to  support  program  execution,  the 
acquisition  strategy  shall  identify  technical,  schedule,  and  funding  critical  path  issues  for  both 
the  acquisition  program  and  the  IT,  including  NSS,  infrastructure  that  could  impact  the  PM's 
ability  to  execute  the  acquisition  strategy.  The  acquisition  strategy  shall  describe  support 
shortfalls  and  issues  and  plans  to  resolve  the  issues,  and  provide  additional  supporting  detail  in 
the  C4ISP. 

C2.7.4.  Protection  of  Critical  Program  Information  and  Anti-Tamper  Measures.  The  PM 
shall  ensure  the  acquisition  strategy  provides  for  compliance  with  the  procedures  regarding 
critical  program  information  and  anti-tamper  measures  in  paragraph  C6.7.5.  The  PM  shall 
identify  in  the  acquisition  strategy,  the  technical,  schedule,  cost,  and  funding  issues  associated 
with  executing  requirements  for  protection  of  critical  program  information  and  technologies,  and 
plans  to  resolve  the  issues. 

C2.8.  SUPPORT  STRATEGY 

C2.8.1 .  As  part  of  the  acquisition  strategy,  the  PM  shall  develop  and  document  a  support 
strategy  for  life-cycle  sustainment  and  continuous  improvement  of  product  affordability, 
reliability,  and  supportability,  while  sustaining  readiness.  This  effort  shall  ensure  that  system 
support  and  life-cycle  affordability  considerations  are  addressed  and  documented  as  an  integral 
part  of  the  program’s  overall  acquisition  strategy.  The  support  strategy  shall  define  the 
supportability  planning,  analyses,  and  trade-offs  conducted  to  determine  the  optimum  support 
concept  for  a  materiel  system  and  strategies  for  continuous  affordability  improvement 
throughout  the  product  life  cycle.  The  support  strategy  shall  continue  to  evolve  toward  greater 
detail,  so  that  by  Milestone  C,  it  contains  sufficient  detail  to  define  how  the  program  will  address 
the  support  and  fielding  requirements  that  meet  readiness  and  performance  objectives,  lower 
TOC,  reduce  risks  and  avoid  harm  to  the  environment  and  human  health.  The  support  strategy 
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shall  address  all  applicable  support  requirements  to  include,  but  not  be  limited  to,  the  following 
elements: 

C2.8. 1 . 1 .  Product  support  (including  software); 

C2 . 8 . 1 .2 .  Affordability  improvements; 

C2.8. 1 .3.  Source  of  support; 

C2.8.1.4.  Human  systems  integration  (HSI); 

C2.8.1.5.  Environment,  safety,  and  occupational  health  (ESOH); 

C2.8.1.6.  Post  deplojunent  evaluation;  and 

C2.8.1.7.  Long-term  access  to  data  to  support  the  following: 

C2. 8. 1.7.1.  Competitive  sourcing  decisions; 

C2.8. 1 .7.2.  Conversion  of  product  configuration  technical  data  to  performance 
specifications  when  required  for  enabling  technology  insertion  to  enhance  product  affordability 
and  prevent  product  obsolescence;  and 

C2.8. 1.7.3.  Contract  service  risk  assessments  over  the  life  of  the  system. 

C2.8.2.  The  support  strategy  is  an  integral  part  of  the  systems  engineering  process  (see 
C5.2.).  Demonstration  of  assured  supportability  and  life-cycle  affordability  shall  be  entrance 
criteria  for  the  Production  and  Deployment  Phase.  The  specific  requirements  associated  with 
integrating  the  support  strategy  into  the  system  engineering  process  shall  be  accomplished 
through  IPPD  (see  C5.1.). 

C2.8.3.  Product  Support.  Product  support  is  a  package  of  logistics  support  functions 
necessary  to  maintain  the  readiness  and  operational  capability  of  a  system  or  subsystems. 

C2.8.3.1.  Product  Support  Management  Plaiming.  The  PM,  in  coordination  with 
Military  Service  logistics  commands,  shall  include  planning  for  full  life-cycle  product  support 
management  as  part  of  the  support  strategy  documented  in  the  acquisition  strategy.  The  plannmg 
shall  include  actions  to  assure  sustainment,  and  to  continually  improve  product  affordability  for 
programs  in  initial  procurement,  reprocurement,  and  post-production  support.  The  planning  shall 
describe  an  integrated  acquisition  and  logistics  strategy  for  the  remaining  life  of  the  system  or 
subsystem.  This  strategy  shall  be  updated  at  least  every  five  years  during  the  product’s  life 
cycle,  or  with  greater  frequency,  depending  on  the  pace  of  technology.  As  a  minimum,  product 
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support  management  planning  shall  address  how  the  program  will  accomplish  the  following 
objectives: 

C2.8.3.1.1.  Integrate  supply  chains  to  achieve  cross-functional  efficiencies  and 
provide  improved  customer  service  through  performance-based  arrangements  or  contracts. 

C2.8.3. 1 .2.  Segment  support  by  system  or  subsystem  and  delineate  agreements  to 
meet  specific  customer  needs. 

C2.8.3.1.3.  Maintain  relationship  with  the  user/warfighter  based  on  system 

readiness. 


C2.8.3.1.4.  Provide  standard  user  interfaces  for  the  customer  via  integrated 
sustainment  support  centers. 

C2.8.3.1.5.  Select  best-value,  long-term  product  support  providers  and  integrators 
based  on  competition. 

C2.8.3.1.6.  Measure  support  performance  based  on  high-level  metrics,  such  as 
availability  of  mission-capable  systems,  instead  of  on  distinct  elements  such  as  parts, 
maintenance,  and  data. 

C2.8.3.1.7.  Improve  product  affordability,  system  reliability,  maintainability,  and 
supportability  via  continuous,  dedicated  investment  in  technology  refreshment  through  adoption 
of  performance  specifications,  commercial  standards,  non-developmental  items,  and 
commercial-off-the-shelf  items  where  feasible,  in  both  the  initial  acquisition  design  phase  and  in 
all  subsequent  modification  and  reprocurement  actions. 

C2. 8.3.2.  Product  Support  Integrator.  The  PM  may  select  a  product  support  integrator 
from  the  DoD  or  private  sector.  Activities  coordinated  by  support  integrators  can  include,  as 
appropriate,  functions  provided  by  organic  organizations,  private  sector  providers,  or  a 
partnership  between  organic  and  private  sector  providers.  The  PM  shall  ensure  that  the  product 
support  concept  is  integrated  with  other  logistics  support  and  combat  support  functions  to 
provide  agile  and  robust  combat  capability.  The  PM  shall  invite  Military  Service  and  Defense 
Logistics  Agency  (DLA)  logistics  activities  to  participate  in  product  support  strategy 
development  and  integrated  product  teams  (IPTs).  These  participants  shall  help  to  ensure 
effective  integration  of  system-oriented  approaches  with  commodity-oriented  approaches 
(common  support  approaches),  optimize  support  to  users,  and  maximize  total  logistics  system 
value. 

C2.8.4.  Somce  of  Support.  The  PM  shall  use  the  most  effective  source  of  support  that 
optimizes  performance  and  life-cycle  cost,  consistent  with  military  requirements.  The  source  of 
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support  may  be  organic  or  commercial,  but  its  primary  focus  is  to  optimize  customer  support  and 
achieve  maximum  weapon  system  availability  at  the  lowest  TOC.  Source  of  support  decisions 
shall  foster  competition  throughout  the  life  of  the  system  (see  section  C2.8.4.2.,  section  C2.9.1., 
and  paragraph  C5.2.3.5.4.3.). 

C2.8.4.1.  Depot  Maintenance  Source  of  Support.  10  U.S.C.  2464  (reference  (p))  and 
DoD  policy  require  organic  core  maintenance  capabilities.  Such  capabilities  provide  effective 
and  timely  response  to  surge  demands,  ensure  competitive  capabilities,  and  sustain  institutional 
expertise.  Within  statutory  limitations,  support  concepts  for  new  and  modified  systems  shall 
maximize  the  use  of  contractor  provided,  long-term,  total  life-cycle  logistics  support  that 
combines  depot-level  maintenance  for  non-core-related  workload  along  with  wholesale  and 
selected  retail  materiel  management  functions.  Best  value  over  the  life  cycle  of  the  system  and 
use  of  existing  contractor  capabilities,  particularly  while  the  system  is  in  production,  shall  be 
considered  as  key  determinants  in  the  overall  decision  process.  The  PM  shall  provide  for  long¬ 
term  access  to  data  required  for  competitive  sourcing  of  systems  support  throughout  its  life 
cycle.  Additional  guidance  appears  in  DoD  Directive  4151.18  (reference  (q))  and  DoD 
Handbook  4151.1 8-H  (reference  (r)). 

C2. 8.4.2.  Supply  Source  of  Support 

C2.8.4.2.1.  It  is  DoD  policy  to  give  the  PM  latitude  in  selecting  a  somce  of  supply 
support,  including  support  management  functions,  that  maximizes  service  to  the  user,  while 
minimizing  cost.  The  PM  shall  select  a  source  of  supply  support  that  gives  the  PM  and/or  the 
support  integrator  sufficient  control  over  financial  and  support  functions  to  effectively  make 
trade-off  decisions  that  affect  system  readiness  and  cost.  The  PM  shall  select  organic  supply 
sources  of  support  when  they  offer  the  best  value.  Particular  attention  shall  be  given  to  Prime 
Vendor  contracts  for  specific  commodities  and  Virtual  Prime  Vendor  contracts  for  a  wide  range 
of  parts  support  for  specific  sub-systems.  When  changing  the  support  strategy  for  fielded 
equipment  from  organic  support  to  contractor  support  or  from  contractor  support  to  organic 
support,  DoD  owned  inventory  that  is  unique  to  that  system  must  be  addressed  in  the  source  of 
support  decision. 

C2.8.4.2.2.  The  PM  shall  use  a  competitive  process  to  select  the  best  value  supply 
support  provider.  Access  to  multiple  sources  of  supply  is  encouraged  to  reduce  the  risks 
associated  with  a  single  source.  Supply  support  may  be  included  as  part  of  the  overall  system 
procurement  or  as  a  separate  competition.  The  competitive  selection  process  will  result  in  a 
contract  with  a  commercial  source  and/or  an  agreement  with  an  organic  source  that  prescribes  a 
level  of  performance  in  terms  of  operational  performance  and  cost.  Additional  guidance  appears 
in  DoD  Directive  4140.1  (reference  (s))  and  DoD  Regulation  4140. 1-R  (reference  (t)). 

C2.8.4.3.  Contractor  Logistics  Support  Integration,  In-Theater.  Civilian  contractors 
execute  support  missions  in  a  variety  of  contingency  environments  and  operations  other  than 
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war.  When  support  strategies  employ  contractors,  PMs  shall  coordinate  with  users  to  identify  the 
standards  and  procedures  for  integrating  contractor  logistics  support  into  the  theater  of 
operations,  per  Joint  Publication  4-0,  Chapter  5  (reference  (u)),  and  Service  implementing 
guidance. 

C2.8.5.  HSI.  The  PM  shall  pursue  HSI  initiatives  (see  paragraph  C5.2.3.5.9.)  to  optimize 
total  system  performance  and  minimize  TOC.  The  PM  shall  integrate  manpower,  personnel, 
training,  safety  and  occupational  health  (see  paragraph  C2.8.6.),  habitability,  human  factors,  and 
personnel  survivability  considerations  into  the  acquisition  process.  The  support  strategy  shall 
identify  responsibilities,  describe  the  technical  and  management  approach  for  meeting  HSI 
requirements,  and  summarize  major  elements  of  the  associated  training  system.  The  following 
considerations  apply: 

C2.8.5.1.  Manpower.  The  support  strategy  shall  document  the  approach  being  used  to 
provide  the  most  efficient  and  cost  effective  mix  of  DoD  manpower  and  contract  support  and 
identify  any  cost  or  schedule  issues  (e.g.,  uncompleted  studies)  that  could  impact  the  PM’s 
ability  to  execute  the  program  (see  paragraph  C4.5.4.1.).  In  all  cases,  the  PM  shall  consult  with 
the  manpower  community  in  advance  of  contracting  for  operational  support  services  to  ensure 
that  sufficient  workload  is  retained  in-house  to  adequately  provide  for  military  career 
progression,  sea-to-shore  or  overseas  rotation,  and  combat  augmentation.  The  PM  shall  ensure 
that  inherently  governmental  and  exempted  commercial  functions  (see  paragraph  C4.5.4.)  are  not 
contracted. 

C2. 8.5.2.  Personnel.  The  PM  shall  summarize  major  personnel  initiatives  that  are 
necessary  to  achieve  readiness  or  rotation  objectives  or  reduce  manpower  or  training  costs.  The 
support  strategy  shall  address  modifications  to  the  knowledge,  skills,  and  abilities  of  military 
occupational  specialties  for  system  operators,  maintainers,  or  support  personnel  if  the 
modifications  have  cost  or  schedule  issues  that  could  adversely  impact  program  execution.  The 
support  strategy  shall  also  address  actions  to  combine,  modify,  or  establish  new  military 
occupational  specialties  or  additional  skill  indicators,  or  issues  relating  to  hard-to-fill  occupations 
if  they  impact  the  PM’s  ability  to  execute  the  program. 

C2.8.5.3.  Training 

C2. 8.5.3. 1.  The  PM  shall  summarize  major  elements  of  the  training  system 
described  in  DoD  Directive  1430.13  (reference  (v)),  in  the  support  strategy,  and  identify  training 
initiatives  that  enhance  the  user’s  capabilities,  improve  readiness,  or  reduce  individual  and 
collective  training  costs.  Planned  training  shall  maximize  the  use  of  new  learning  techniques, 
simulation  technology,  embedded  training,  and  instrumentation  systems  to  provide  anytime, 
anyplace  training  that  reduces  the  demand  on  the  training  establishment  and  reduces  TOC.  The 
PM  shall  work  with  the  training  commimity  to  develop  options  for  individual,  collective,  and 
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joint  training  for  the  personnel  who  will  operate,  maintain,  support,  and  provide  training  for  the 
system. 


C2.8.5.3.2.  For  non-IT,  including  non-NSS,  interoperability  training  issues,  and  for 
IT,  including  NSS,  interoperability  issues  not  addressed  in  the  C4ISP  (see  section  C6.4.  and 
Appendix  5),  the  acquisition  strategy  shall  include  a  description  of  interoperability  requirements 
necessary  to  support  xmit  and  joint  training  architectures.  For  those  programs  that  require 
training  infrastructure  modifications,  the  PM  shall  identify  technical,  schedule,  and  funding 
issues  that  impact  execution. 

C2.8.5.4.  Personnel  Survivability  and  Habitability.  For  systems  with  missions  that 
might  expose  it  to  combat  threats,  the  PM  shall  address  personnel  survivability  issues  including 
protection  against  fratricide,  detection,  and  instantaneous,  cumulative,  and  residual  nuclear, 
biological,  and  chemical  effects;  the  integrity  of  the  crew  compartment;  and  provisions  for  rapid 
egress  when  the  system  is  severely  damaged  or  destroyed.  If  the  system  or  program  has  been 
designated  by  DOT&E  for  live  fire  test  and  evaluation  (LFT&E)  oversight  (see  section  C3.3.), 
the  PM  shall  integrate  T&E  to  address  crew  survivability  issues  into  the  LFT&E  program  to 
support  the  Secretary  of  Defense  LFT&E  Report  to  Congress  (see  paragraph  C3.1 1.2.)  (10 
U.S.C.  2366  (reference  (w))).  The  PM  shall  address  special  equipment  or  gear  needed  to  sustain 
crew  operations  in  the  operational  environment  (see  paragraph  C5.2.3.5.9.2.).  The  PM  shall  also 
address  habitability  requirements  (e.g.,  for  the  physical  environment  and  support  services)  that 
are  necessary  for  meeting  and  sustaining  system  performance,  avoiding  personnel  retention 
problems,  maintaining  quality  of  life,  and  minimizing  total  system  costs. 

C2.8.5.5.  Human  Factors  Engineering  (HFE).  The  PM  shall  summarize  steps  being 
taken  (e.g.,  contract  deliverables  or  govemment/contractor  IPT  teams)  to  ensure  the  proper 
employment  of  HFE/cognitive  engineering  during  systems  engineering  (see  paragraph 
C5.2.3. 5.9.1.)  to  provide  for  effective  human-machine  interfaces,  meet  HSI  requirements,  and  (as 
appropriate)  support  a  family-of-systems  acquisition  approach. 

C2.8.6.  Environment,  Safety,  and  Occupational  Health  (ESOH)  Considerations.  As  part  of 
risk  reduction,  the  PM  shall  prevent  ESOH  hazards,  where  possible,  and  shall  manage  ESOH 
hazards  where  they  cannot  be  avoided.  The  support  strategy  shall  contain  a  summary  of  the 
Programmatic  ESOH  Evaluation  (PESHE)  document,  including  ESOH  risks,  a  strategy  for 
integrating  ESOH  considerations  into  the  systems  engineering  process,  identification  of  ESOH 
responsibilities,  and  a  method  for  tracking  progress  (see  section  C5.2.3.5.10.). 

C2.8.7.  Demilitarization  and  Disposal  Planning 

C2.8.7.1.  During  systems  engineering,  the  PM  shall  consider  materiel  demilitarization 
and  disposal.  The  PM  shall  minimize  DoD’s  liability  due  to  information  and  technology 
security,  environmental,  safety,  and  occupational  health  issues.  The  PM  shall  coordinate  with 
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Service  logistics  activities  and  DLA,  as  appropriate,  to  identify  and  apply  applicable 
demilitarization  requirements  necessary  to  eliminate  the  functional  or  military  capabilities  of 
assets  (DoD  4140. 1-R  (reference  (t))  and  DoD  4160.21-M-l  (reference  (x))).  The  PM  shall 
coordinate  with  DLA  to  determine  reutilization  and  hazardous-property  disposal  requirements 
for  system  equipment  and  by-products  (reference  (t)  and  DoD  4160.21-M  (reference  (y))). 

C2. 8.7.2.  For  munitions  programs,  the  PM  shall  document  the  parts  of  the  system  that 
will  require  demilitarization  and  disposal,  and  address  the  inherent  dangers  associated  with 
ammunition  and  explosives.  This  documentation  shall  be  in  place  before  the  start  of 
developmental  test  and  evaluation  and  before  the  PM  releases  munitions  or  explosives  to  a  non¬ 
military  setting.  The  documentation  shall  provide  the  following:  render  safe  procedures;  step- 
by-step  procedures  for  disassembling  the  munition  item(s)  to  the  point  necessary  to  gain  access 
to  and/or  to  remove  the  energetic  and  hazardous  materials;  and  identification  of  all  energetics 
and  hazardous  materials,  and  the  associated  waste  streams  produced  by  the  preferred 
demilitarization/disposition  process. 

C2.8.7.3.  Demilitarization  and  disposal  planning  shall  not  consider  open  bum  and  open 
detonation  as  the  primary  methods  of  demilitarization  or  disposal. 

C2.8.8.  Life-Cycle  Support  Oversight.  The  support  strategy  shall  address  how  the  PM  and 
other  responsible  organizations  will  maintain  appropriate  oversight  of  the  fielded  system. 
Oversight  shall  identify  and  properly  address  performance,  readiness,  ownership  cost,  and 
support  issues,  and  shall  include  post  deployment  evaluation  to  support  planning  for  assuring 
sustainment  and  implementing  technology  insertion,  to  continually  improve  product 
affordability.  Oversight  shall  be  consistent  with  the  written  charter  of  the  PM’s  authority, 
responsibilities,  and  accountability  for  accomplishing  approved  program  objectives  (see  DoD 
Instruction  5000.2,  Section  4  (reference  (a))). 

C2.8.9.  Post  Deployment  Evaluation.  The  PM  shall  use  post  deployment  evaluations  of  the 
system,  beginning  at  IOC,  to  verify  whether  the  fielded  system  continues  to  meet  or  exceed 
thresholds  and  objectives  for  cost,  performance,  and  support  parameters  approved  at  full  rate 
production.  The  PM  shall  select  the  parameters  for  evaluations  based  on  their  relevance  to  future 
modifications  or  evolutionary  block  upgrades  for  performance,  sustainability,  and  affordability 
improvements,  or  when  there  is  a  high  level  of  risk  that  a  KPP  will  not  be  sustained  over  the  life 
of  the  system.  The  PM  shall  include  these  parameters  in  the  APB  and  report  them  in  the  Defense 
Acquisition  Executive  Summary  (DAES)  (see  section  C7.15.3.  and  Appendix  1)  for  the  period  of 
time  specified  in  the  support  strategy.  Post  deployment  evaluations  shall  continue  as  operational 
support  plans  execute  (including  transition  fi'om  organic  to  contract  support  and  vice  versa,  if 
applicable),  and  shall  be  regularly  updated  depending  on  the  pace  of  technology.  The  PM  shall 
use  existing  reporting  systems  and  operational  feedback  to  evaluate  the  fielded  system  whenever 
possible. 


41 


CHAPTER 2 


DoD  5000,2-^R,  June  2001 


C2.9.  BUSINESS  STRATEGY 

As  part  of  the  acquisition  strategy,  the  PM  shall  develop  and  document  a  business  strategy. 

C2.9.1.  Competition.  The  acquisition  strategy  for  all  acquisition  programs  shall  describe 
plans  to  attain  program  goals  via  competition,  throughout  all  phases  of  the  program’s  life  cycle, 
or  explain  why  competition  is  neither  practicable  nor  in  the  best  interests  of  the  Government. 

C2.9.1.1.  Fostering  a  Competitive  Environment 

C2.9. 1 . 1 . 1 .  Competition  Advocates.  The  Head  of  each  DoD  Component  with 
acquisition  responsibilities  shall  designate  a  competition  advocate  for  the  Component  and  for 
each  procurement  activity  (41  U.S.C.  418  (reference  (z))  and  10  U.S.C.  2318  (reference  (aa))). 
The  advocate  for  competition  for  each  procurement  activity  shall  be  responsible  for  promoting 
full  and  open  competition,  promoting  the  acquisition  of  commercial  items,  and  challenging 
barriers  to  such  acquisition,  including  such  barriers  as  unnecessarily  restrictive  statements  of 
need,  unnecessarily  detailed  specifications,  and  unnecessarily  burdensome  contract  clauses.  The 
DoD  Competition  Advocate  and  the  Competition  Advocates  in  the  Military  Departments  shall  be 
at  the  general/flag  officer  rank  or  the  senior  executive  service  level  (reference  (aa)). 

C2.9. 1 . 1 .2.  Ensuring  Future  Competition  for  Defense  Products 

C2.9.1.1.2.1.  The  decline  in  defense  spending  and  subsequent  industry 
consolidation  have  created  a  new  industrial  environment  that  DoD  must  consider  when  making 
acquisition  and  technology  program  decisions.  For  some  critical  and  complex  Defense  products, 
the  number  of  competitive  suppliers  is  now,  or  will  be,  limited.  While  it  is  fundamental  DoD 
policy  to  rely  on  the  marketplace  to  meet  Department  requirements,  there  may  be  exceptional 
circumstances  in  which  the  Department  needs  to  act  to  maintain  future  competition. 

Accordingly,  DoD  Components  shall  consider  the  effects  of  their  acquisition  and  budget  plans  on 
fiiture  competition. 

C2.9.1.1.2.2.  The  Deputies  to  CAEs  shall  confer  routinely  with  the  Deputy 
Under  Secretary  of  Defense  (Industrial  Affairs)  (DUSD(IA))  to  discuss  areas  where  future 
competition  may  be  limited  and  provide  the  DUSD(IA)  with  information  on  such  areas  based  on 
reporting  from  program  managers  and  other  sources.  This  group  will  review  such  areas  that  have 
been  identified  by  program  acquisition  strategies,  IPTs,  sole-source  Justifications  and  Approvals, 
and  more  generally  from  industry  sources.  Where  appropriate,  this  group  shall  establish  a  DoD 
team  to  evaluate  specific  product  or  technology  areas.  Based  on  analysis  and  findings  of  the 
team,  the  USD(AT&L)  will  decide  what,  if  any,  DoD  action  is  required  to  ensure  future 
competition  in  the  sector  involved.  USD(AT&L)  shall  direct  any  proposed  changes  in  specific 
programs  or  direct  the  MDA  to  make  such  changes  to  a  specific  program. 
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C2.9.1.2.  Building  Competition  into  Individual  Acquisition  Strategies.  PMs  and 
contracting  officers  shall  provide  for  fiill  and  open  competition,  unless  one  of  the  limited 
statutory  exceptions  applies  (FAR  Subpart  6.3  (reference  (bb))).  PMs  and  contracting  officers 
shall  use  competitive  procedures  best  suited  to  the  circumstances  of  the  acquisition  program.  To 
comply  with  these  policies,  PMs  shall  plan  for  competition  from  the  inception  of  program 
activity.  Such  competition  planning  shall  precede  preparation  of  an  acquisition  strategy  when, 
for  example,  a  technology  project  or  an  effort  involving  advanced  development  or  demonstration 
activities  has  potential  to  transition  into  an  acquisition  program.  Competition  planning  must 
include  the  immediate  effort  being  undertaken  and  any  foreseeable  future  procurement  as  part  of 
an  acquisition  program.  Competitive  prototyping,  competitive  alternative  sources,  and 
competition  with  other  systems  that  may  be  able  to  accomplish  the  mission  shall  be  used  where 
practicable. 


C2.9. 1.2.1.  Applying  Competition  to  Acquisition  Phases.  The  acquisition  strategy 
prepared  to  support  program  initiation  shall  include  plans  for  competition  for  the  long  term.  The 
strategy  shall  be  structured  to  make  maximum  use  of  competition  through  the  life  of  the 
contemplated  program  to  achieve  performance  and  schedule  requirements,  improve  product 
quality  and  reliability,  and  reduce  cost. 

C2.9. 1.2.2.  Applying  Competition  to  Evolutionary  Acquisition 

C2.9.1. 2.2.1.  An  evolutionary  acquisition  strategy  must  be  based  on  time- 
phased  requirements,  consisting  of  an  initial  block  of  capability,  and  some  number  of  subsequent 
blocks  necessary  to  provide  the  full  capability  required.  Plans  for  competition  must  be  tailored 
to  the  nature  of  each  block,  and  the  relationship  of  the  successive  blocks  to  each  other.  For 
example,  if  each  block  adds  a  discrete  capability  in  a  segregable  package  to  a  pre-established 
modular  open  system  architecture,  it  may  be  possible  and  desirable  to  obtain  full  and  open 
competition  for  each  block.  If  each  successive  block  enhances  capability  by  building  on  its 
predecessor,  such  that  it  is  necessary  that  the  supplier  of  the  first  block  also  create  the  next  block, 
then  competition  for  the  initial  block  may  establish  the  sole  source  for  subsequent  blocks. 

C2.9.1. 2.2.2.  There  is  no  presumption  that  successive  blocks  must  be 
developed  or  produced  by  the  same  contractor.  The  acquisition  strategy  shall: 

C2.9. 1 .2.2.2. 1 .  Describe  the  plan  for  competition  for  the  initial  block. 
State  how  the  solicitation  will  treat  the  initial  block,  and  why.  For  example,  the  first  block  may 
be: 


C2.9. 1 .2 .2.2. 1 . 1 .  A  stand-alone  requirement,  independent  of  any 
future  procurements  of  subsequent  blocks; 
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C2.9.1. 2.2.2. 1.2.  The  first  in  a  series  of  time-phased  requirements,  all 
of  which  are  expected  to  need  to  be  satisfied  by  the  same  prime  contractor. 

C2.9. 1.2.2.2.2.  State,  for  each  successive  block,  whether  competition  at 
the  prime  contract  level  is  practicable,  and  why. 

C2.9.1.2.2.2.2.1.  When  competition  is  practicable,  explain  plans  for 
the  transition  from  one  block  to  the  next  if  there  is  a  different  prime  contractor  for  each,  and  the 
manner  in  which  integration  issues  will  be  addressed. 

C2.9.1.2.2.2.2.2.  When  competition  is  not  planned  at  the  prime 
contract  level,  identify  the  FAR  Part  6  reason  for  using  other  than  full  and  open  competition; 
explain  how  long,  in  terms  of  contemplated  successive  blocks,  the  sole  source  is  expected  to  be 
necessary;  and  address  when  and  how  competition  will  be  introduced,  including  plans  for 
bringing  competitive  pressure  to  bear  on  the  program  through  competition  at  major  subcontractor 
or  lower  tiers  or  through  other  means. 

C2.9.1.2.3.  Industry  Involvement.  DoD  policy  encoxirages  early  industry 
involvement  in  the  acquisition  effort,  consistent  with  the  Federal  Advisory  Committee  Act 
(FACA)  (reference  (cc))  and  FAR  Part  15  (reference  (dd)).  The  acquisition  strategy  shall 
describe  past  and  planned  industry  involvement.  The  PM  shall  apply  knowledge  gained  from 
industry  when  developing  the  acquisition  strategy;  however,  with  the  exception  of  the  PM's 
support  contractors,  industry  shall  not  directly  participate  in  acquisition  strategy  development. 

C2.9.1.3.  Potential  Obstacles  to  Competition 

C2. 9. 1.3.1.  Exclusive  Teaming  Arrangements.  Two  or  more  companies  create  an 
exclusive  teaming  arrangement  when  they  agree  to  team  to  pursue  a  DoD  acquisition  program, 
and  agree  not  to  team  with  other  competitors  for  that  program.  These  teaming  arrangements 
occasionally  result  in  inadequate  competition  for  DoD  contracts.  While  the  Department’s 
preference  is  to  allow  the  private  sector  to  team  and  subcontract  without  DoD  involvement,  the 
Department  shall  intervene,  if  necessary,  to  assure  adequate  competition.  The  MDA  shall 
approve  any  action  to  break  up  a  team. 

C2.9. 1 .3.2.  Sub-Tier  Competition 

C2.9.1. 3.2.1.  All  acquisition  programs  shall  foster  competition  at  sub-tier 
levels,  as  well  as  at  the  prime  level.  The  PM  shall  focus  on  critical  product  and  technology 
competition  when  formulating  the  acquisition  strategy;  when  exchanging  information  with 
industry;  and  when  managing  the  program  system  engineering  and  Ufe  cycle. 
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C2.9.1.3.2.2.  Preparation  of  the  acquisition  strategy  shall  include  an  analysis 
of  product  and  technology  areas  critical  to  meeting  program  needs.  The  acquisition  strategy 
shall  identify  the  potential  industry  sources  to  supply  these  needs.  The  acquisition  strategy  shall 
highlight  areas  of  potential  vertical  integration  (i.e.,  where  potential  prime  contractors  are  also 
potential  suppliers).  Vertical  integration  may  be  detrimental  to  DoD  interests  if  a  firm  employs 
internal  capabilities  without  consideration  of,  or  despite  the  superiority  of,  the  capabilities  of 
outside  sources.  The  acquisition  strategy  shall  describe  the  approaches  the  PM  will  use  (e.g., 
requiring  an  open  systems  architecture,  investing  in  alternate  technology  or  product  solutions, 
breaking  out  a  subsystem  or  component,  etc.)  to  establish  or  maintain  access  to  competitive 
suppliers  for  critical  areas  at  the  system,  subsystem,  and  component  levels. 

C2.9.1.3.2.3.  During  early  exchanges  of  information  with  industry  (e.g.,  the 
draft  request  for  proposal  process),  PMs  shall  identify  the  critical  product  and  technology  areas 
that  the  primes  plan  to  provide  internally  or  through  exclusive  teaming.  The  PM  shall  assess  the 
possible  competitive  effects  of  these  choices.  The  PM  shall  take  action  to  mitigate  areas  of  risk. 
If  the  action  requires  a  change  to  the  approved  acquisition  strategy,  the  PM  shall  recommend  the 
needed  change  to  the  MDA. 

C2.9.1. 3.2.4.  As  the  designs  evolve,  the  PM  shall  continue  to  analyze  how  the 
prime  contractor  is  addressing  the  program's  critical  product  and  technology  areas.  This  analysis 
may  identify  areas  where  the  design  unnecessarily  restricts  subsystem  or  component  choices. 
Contractors  shall  be  challenged  during  requirements  and  design  reviews  to  support  why  planned 
materiel  solutions  for  subsystem  and  component  requirements  critical  to  the  program  are 
appropriate  when  other  choices  are  available.  This  monitoring  shall  continue  through  the  system 
life  cycle  (e.g.,  reprocurements,  logistics  support). 

C2.9.1.4.  Potential  Sources.  The  PM  shall  consider  both  international  (consistent  with 
possible  information  security  and  technology  transfer  restrictions)  and  domestic  sources  that  can 
meet  the  need,  and  consider  both  commercial  and  non-developmental  items  as  the  primary 
source  of  supply,  consistent  with  FAR  Part  25  (reference  (ee))  and  Defense  Federal  Acquisition 
Regulation  Supplement  (DFARS)  Part  225  (reference  (ff)).  The  PM  shall  consider  national 
policies  on  contracting  and  subcontracting  with  small  business  (15  U.S.C.  644(a)  (reference  (gg)) 
&  15  U.S.C.  644(j)  (reference  (hh))),  small  and  disadvantaged  business  (15  U.S.C.  637(d)(4)-(6) 
(reference  (ii))),  women-owned  small  business  (Pub.  L.  100-533  (1988)  (reference  (jj))),  and 
labor  surplus  areas  (15  U.S.C.  644(d)  (reference  (kk))),  and  address  considerations  to  secure 
participation  of  these  entities  at  both  prime  and  sub-tier  levels.  The  PM  shall  consider  intra- 
government  work  agreements,  i.e.,  formal  agreements,  project  orders  or  work  requests,  in  which 
one  government  activity  agrees  to  perform  work  for  another,  creating  a  supplier/customer 
relationship. 


C2.9.1.4. 1.  Market  Research.  The  PM  shall  use  market  research  as  a  primary 
means  to  determine  the  availability  and  suitability  of  commercial  and  non-developmental  items. 
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and  the  extent  to  which  the  interfaces  for  these  items  have  broad  market  acceptance,  standards- 
organization  support,  and  stability.  Market  research  shall  support  the  acquisition  planning  and 
decision  process,  supplying  technical  and  business  information  about  commercial  technology 
and  industrial  capabilities.  Market  research,  tailored  to  program  needs  shall  continue  throughout 
the  acquisition  process  and  during  post-production  support.  FAR  Part  10  (reference  (11))  requires 
the  acquisition  strategy  to  include  the  results  of  completed  market  research  and  plans  for  future 
market  research. 

C2.9. 1 .4.2.  Commercial  and  Non-Developmental  Items 

C2.9.1. 4.2.1.  The  PM  shall  use  sources  of  supply  that  provide  for  the  most 
cost-effective  system  throughout  its  life  cycle.  The  PM  shall  work  with  the  user  to  define  and 
modify,  as  necessary,  requirements  to  facilitate  the  use  of  commercial  and  non-developmental 
items.  This  includes  requirements  for  hardware,  software,  interoperability,  data  interchange, 
packaging,  transport,  delivery,  and  automatic  test  systems.  Within  the  constraints  of  these 
requirements,  the  PM  shall  require  contractors  and  subcontractors  to  use  commercial  and  non- 
developmental  items  to  the  maximum  extent  possible.  While  some  commercial  items  may  not 
meet  system-level  requirements  for  ACAT I  and  lA  programs,  numerous  commercial 
components,  processes,  practices,  and  technologies  have  application  to  DoD  systems.  This 
policy  shall  extend  to  subsystems,  components,  and  spares  levels  based  on  the  use  of 
performance  specifications  and  form,  fit,  function  and  interface  specifications.  Preference  shall 
be  first  to  commercial  items,  then  to  non-developmental  items.  FAR  Section  2.101  (reference 
(mm))  contains  definitions  of  commercial  and  non-developmental  items. 

C2.9.1. 4.2.2.  The  commercial  market  place  widely  accepts  and  supports  open 
interface  standards,  set  by  recognized  standards  organizations.  These  standards  support 
interoperability,  portability,  scalability,  and  technology  insertion.  When  selecting  commercial  or 
non-developmental  items,  the  PM  shall  prefer  open  interface  standards  and  commercial  item 
descriptions.  If  acquiring  products  with  closed  interfaces,  the  PM  shall  conduct  a  business  case 
analysis  to  justify  acceptance  of  the  associated  economic  impacts  on  TOC  and  risks  to 
technology  insertion  and  maturation  over  the  service  life  of  the  system. 

C2.9. 1.4.3.  Dual-Use  Technologies  and  the  Use  of  Commercial  Plants 

C2.9.1. 4.3.1.  Dual-use  technologies  are  technologies  that  meet  a  military  need, 
yet  have  sufficient  commercial  application  to  support  a  viable  production  base.  Market  research 
and  analysis  shall  identify  and  evaluate  possible  dual-use  technology  and  component 
development  opportunities.  Solicitation  document(s)  shall  encourage  offerors  to  use,  and  the  PM 
shall  give  consideration  to,  dual-use  technologies  and  components.  System  design  shall  facilitate 
the  later  insertion  of  leading  edge,  dual-use  technologies  and  components  throughout  the  system 
life  cycle. 
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C2.9.1.4.3.2.  Solicitation  document(s)  shall  encourage  offerors  to  use 
commercial  plants  and  integrate  military  production  into  commercial  production  as  much  as 
possible. 


C2. 9. 1.4.4.  Industrial  Capability 

C2.9.1. 4.4.1.  The  acquisition  strategy  shall  summarize  an  analysis  of  the 
industrial  base  capability  to  design,  develop,  produce,  support,  and,  if  appropriate,  restart  the 
program  (10  U.S.C.  2440  (reference  (nn)))  as  appropriate  for  the  next  program  phase.  This 
analysis  (see  DoD  Directive  5000.60  (reference  (oo))  and  DoD  Handbook  5000.60-H  (reference 
(pp)))  shall  identify  DoD  investments  needed  to  create  or  enhance  certain  industrial  capabilities, 
and  the  risk  of  industry  being  unable  to  provide  program  design  or  manufactunng  capabilities  at 
planned  cost  and  schedule.  If  the  analysis  indicates  an  issue  beyond  the  scope  of  the  program, 
the  PM  shall  notify  the  MDA  through  the  PEG.  When  there  is  an  indication  that  industrial 
capabilities  needed  by  DoD  are  in  danger  of  being  lost,  DoD  Components  shall  perform  an 
analysis  to  determine  whether  government  action  is  required  to  preserve  an  industrial  capability 
vital  to  national  security.  Prior  to  completing  or  terminating  production,  Components  shall 
ensure  an  adequate  industrial  capability  and  capacity  to  meet  post-production  operational  needs. 
Actions  shall  address  product  technology  obsolescence,  replacement  of  limited-life  items, 
regeneration  options  for  unique  manufacturing  processes,  and  conversion  to  performance 
requirements  at  the  subsystems,  component,  and  spares  levels. 

C2.9.1. 4.4.2.  In  many  cases,  commercial  demand  now  sustains  the  national 
and  international  technology  and  industrial  base.  The  PM  shall  structure  the  acquisition  strategy 
to  promote  sufficient  program  stability  to  encourage  industry  to  invest,  plan,  and  bear  risks. 
Programs  shall  minimize  the  need  for  new  defense-unique  industrial  capabilities.  Foreign 
sources  and  international  cooperative  development  shall  be  used  where  advantageous  and  within 
limitations  of  the  law  (DFARS  Part  225  (reference  (ff))). 

C2.9.1.5.  Small  Business  Innovation  Research  (SBIR)  Technologies.  The  PM  shall 
develop  an  acquisition  strategy  that  plans  for  the  use  of  technologies  developed  under  the  SBIR 
program,  and  gives  favorable  consideration  for  funding  of  successful  SBIR  technologies.  At 
milestone  and  appropriate  program  reviews  for  ACAT I  programs,  the  PM  shall  address  the 
program’s  plans  for  funding  the  further  development  and  insertion  into  the  program  of  SBIR- 
developed  technologies.  A  searchable  database  of  SBIR-funded  technologies  exists  at 
http://www.acq.osd.mi1/sadbu/sbir/sitemap.html#awards. 

C2.9.2.  International  Cooperation.  The  globalization  of  today's  economy  requires  a  high 
degree  of  coordination  and  international  cooperation.  Consistent  with  possible  information 
security  and  technology  transfer  limitations,  the  PM  shall  adhere  to  the  following  guidelines. 
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C2.9.2.1.  International  Cooperative  Strategy.  The  acquisition  strategy  shall  discuss  the 
potential  for  increasing,  enhancing,  and  improving  the  conventional  forces  of  the  North  Atlantic 
Treaty  Organization  (NATO)  and  the  U.S.,  including  reciprocal  defense  trade  and  cooperation, 
and  international  cooperative  research,  development,  production,  and  logistic  support.  The 
acquisition  strategy  shall  also  consider  the  possible  sale  of  military  equipment.  The  discussion 
shall  identify  similar  projects  under  development  or  in  production  by  a  U.S.  ally.  The  acquisition 
strategy  shall  assess  whether  the  similar  project  could  satisfy  U.S.  requirements,  and  if  so, 
recommend  designating  the  program  an  International  Cooperative  Program.  The  MDA  shall 
review  and  approve  the  acquisition  strategy  for  all  programs  at  each  acquisition  program 
decision  in  accordance  with  10  U.S.C.  2350a  (reference  (qq)),  paragraph  (e).  All  international 
considerations  shall  remain  consistent  with  the  maintenance  of  a  strong  national  technology  and 
industrial  base  and  mobilization  capability.  Restricted  foreign  competition  for  the  program,  due 
to  industrial  base  considerations,  shall  require  prior  USD(AT&L)  approval.  Results  of  T&E  of 
systems  using  approved  International  Test  Operating  procedures  may  be  accepted  without 
repeating  the  testing. 

C2.9.2.2.  International  Interoperability.  The  growing  requirement  for  effective 
international  coalitions  requires  a  heightened  degree  of  international  interoperability.  Reciprocal 
trade  and  cooperative  programs  with  allies  and  friendly  nations  serves  this  end.  Programs  shall 
strive  to  achieve  deployment  and  sustainability  of  interoperable  systems  with  our  potential 
coalition  partners. 

C2.9.2.3.  International  Cooperation  Compliance 

C2.9.2.3. 1.  To  promote  increased  consideration  of  international  cooperation  and 
interoperability  issues  early  in  the  development  process,  the  PM  shall,  at  each  acquisition 
program  milestone,  discuss  cooperative  opportunities  in  the  acquisition  strategy  (10  U.S.C. 

2350a  (reference  (qq))),  including: 

C2.9.2.3.1 .1.  Provide  a  statement  indicating  whether  or  not  a  project  sumlar  to 
the  one  vmder  consideration  is  in  development  or  production  by  one  or  more  major  allies  or 
NATO  organizations. 

C2.9.2.3.1.2.  If  there  is  such  a  project,  provide  an  assessment  as  to  whether 
that  project  could  satisfy,  or  be  modified  in  scope  to  satisfy,  U.S.  military  requirements. 

C2.9.2.3.1.3.  Provide  an  assessment  of  the  advantages  and  disadvantages,  with 
regard  to  program  timing,  life-cycle  costs,  technology  sharing,  standardization,  and 
interoperability,  of  a  cooperative  program  with  one  or  more  major  allies  or  NATO  organizations. 

C2.9.2.3.2.  PMs  shall  always  give  priority  consideration  to  the  most  efficient  and 
cost-effective  solution  over  the  system's  life  cycle.  Generally,  use  or  modification  of  systems  or 
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equipment  that  the  Department  already  owns  is  more  cost-  and  schedule-effective  than  acquiring 
new  materiel. 

C2.9.2.4.  Testing  Required  for  Foreign  Military  Sales.  An  ACAT I  or  II  system  that 
has  not  successfully  completed  initial  operational  test  and  evaluation  (lOT&E)  shall  require 
USD(AT&L)  approval  prior  to  any  foreign  military  sale,  commitment  to  sell,  or  DoD  agreement 
to  license  for  export.  This  policy  does  not  preclude  government-sponsored  discussions  of 
potential  cooperative  opportunities  with  allies  or  reasonable  advance  business  planning  or 
marketing  discussions  with  potential  foreign  customers  by  defense  contractors,  provided 
appropriate  authorizing  licenses  are  in  place. 

C2.9.3.  Contract  Approach 

C2.9.3. 1 .  Major  Contract(s)  Planned.  For  each  major  contract  planned  to  execute  the 
acquisition  strategy,  the  acquisition  strategy  shall  describe  what  the  basic  contract  buys;  how 
major  deliverable  items  are  defined;  options,  if  any,  and  prerequisites  for  exercising  them;  and 
the  events  established  in  the  contract  to  support  appropriate  exit  criteria  for  the  phase  or 
intermediate  development  activity.  The  PM  shall  use  modular  contracting,  as  described  in  FAR 
Section  39.103  (reference  (rr)),  for  major  IT  acquisitions,  to  the  extent  practicable.  PMs  shall 
consider  using  modular  contracting  for  other  acquisition  programs.  In  accordance  with  10 
U.S.C.  2306b  (reference  (ss)),  the  acquisition  strategy  shall  address  the  PM’s  consideration  of 
multiyear  contracting  for  full  rate  production,  and  address  the  PM’s  assessment  of  whether  the 
production  program  is  suited  to  the  use  of  multiyear  contracting  based  on  the  requirements  in 
FAR  Subpart  17.1  (reference  (tt)). 

C2.9.3.2.  Contract  Type.  For  each  major  contract,  the  acquisition  strategy  shall 
identify  the  type  of  contract  planned  (e.g.,  firm  fixed-price  (FFP);  fixed  price  incentive,  firm 
target;  cost  plus  incentive  fee;  or  cost  plus  award  fee)  and  the  reasons  it  is  suitable,  including 
considerations  of  risk  assessment  and  reasonable  risk-sharing  by  the  Government  and  the 
contractor(s).  Fixed  price  development  contracts  of  $25  million  or  more  or  fixed  price  type 
contracts  for  lead  ships  shall  require  the  prior  approval  of  the  USD(AT&L)  (DFARS  Section 
235.006  (reference  (uu))),  regardless  of  a  program’s  ACAT. 

C2.9.3.3.  Contract  Incentives.  The  acquisition  strategy  shall  explain  the  planned 
contract  incentive  structure,  and  how  it  incentivizes  the  contractor(s)  to  provide  the  contracted 
product  or  services  at  or  below  the  established  cost  objectives  (see  section  Cl.3.4.).  If  more  than 
one  incentive  is  planned  for  a  contract,  the  acquisition  strategy  shall  explain  how  the  incentives 
complement  each  other  and  ensure  the  incentives  will  not  interfere  with  one  another. 
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C2.9.3.4.  Integrated  Contract  Performance  Management 

C2.9.3.4. 1.  The  PM  shall  obtain  integrated  cost  and  schedule  performance  data  to 
monitor  program  execution.  The  PM  shall  require  contractors  to  use  internal  management 
control  systems  that  produce  data  that  a)  indicate  work  progress;  b)  properly  relate  cost, 
schedule,  and  technical  accomplishment;  c)  are  valid,  timely  and  able  to  be  audited;  and  d) 
provide  DoD  PMs  with  information  at  a  practical  level  of  summarization.  Unless  waived  by  the 
MDA,  the  PM  shall  require  that  contractors’  management  information  systems  used  in  planning 
and  controlling  contract  performance  meet  the  Earned  Value  Management  Systems  (EVMS) 
guidelines  set  forth  in  American  National  Standards  Institute/EIA  748-98,  Chapter  2  (reference 
(w))  (see  Appendix  4).  The  PM  shall  not  require  a  contractor  to  change  its  system  provided  it 
meets  these  guidelines,  nor  shall  the  PM  impose  a  single  system  or  specific  method  of 
management  control.  These  guidelines  shall  not  be  used  as  a  basis  for  reimbursing  costs  or 
making  progress  payments. 

C2.9.3.4.2.  The  PM  shall  apply  EVMS  guidelines  on  applicable  contracts  within 
acquisition,  upgrade,  modification,  or  materiel  maintenance  programs,  including  highly  sensitive 
classified  programs,  major  construction  programs,  and  other  transaction  agreements.  EVMS 
guidelines  shall  apply  to  contracts  executed  with  foreign  governments,  project  work  performed 
in  government  facilities,  and  contracts  by  specialized  organizations  such  as  the  Defense 
Advanced  Research  Projects  Agency.  EVMS  guidelines  shall  apply  to  research,  development, 
test,  and  evaluation  contracts,  subcontracts,  other  transaction  agreements,  and  intra-govemment 
work  agreements  with  a  value  of  $73  million  or  more  (in  FY  2000  constant  dollars),  or 
procurement  or  operations  and  maintenance  contracts,  subcontracts,  other  transaction 
agreements,  and  intra-govemment  work  agreements  with  a  value  of  $315  million  or  more  (in  FY 
2000  constant  dollars).  Use  DFARS  Clauses  252.234-7000  (reference  (ww))  and  252.234-7001 
(reference  (xx))  to  place  EVMS  requirements  in  solicitations  and  contracts. 

C2.9.3.4.3.  The  C/SSR  (see  7.15.7.3)  shall  apply  to  contracts,  subcontracts,  other 
transaction  agreements,  or  intra-govemment  work  agreements  below  these  thresholds,  unless  the 
PM  requires  EVMS  compliance.  Use  DFARS  Clauses  252.242-7005  (reference  (yy))  and 
252.242-7006  (reference  (zz))  to  place  Cost/Schedule  Status  Report  (C/SSR)  requirements  in 
solicitations  and  contracts. 

C2.9.3.4.4.  The  PM  shall  not  require  compliance  with  EVMS  guidelines  or  C/SSR 
requirements  on  FFP  contracts  (including  FFP  contracts  with  economic  price  adjustment 
provisions),  time  and  materials  contracts,  and  contracts  that  consist  mostly  of  level-of-effort 
work.  For  exceptions  to  this  mle,  the  PM  shall  obtain  a  waiver  for  individual  contracts  from  the 
MDA. 


C2.9.3.5.  Integrated  Baseline  Reviews.  PMs  and  their  technical  staffs  or  IPTs  shall 
evaluate  contract  performance  risks  inherent  in  the  contractor’s  planning  baseline.  This 
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evaluation  shall  be  initiated  within  6  months  after  contract  award  or  intra-govemment  agreement 
is  reached  for  all  contracts  requiring  EVMS  or  C/SSR  compliance. 

C2.9.3.6.  Special  Contract  Terms  and  Conditions.  The  acquisition  strategy  shall 
identify  any  imusual  contract  terms  and  conditions  and  all  existing  or  contemplated  deviations  to 
the  FAR  or  DFARS. 

C2. 9.3.7.  Warranties.  The  PM  shall  examine  the  value  of  warranties  on  major  systems 
and  pursue  them  when  appropriate  and  cost-effective.  If  appropriate,  the  PM  shall  incorporate 
warranty  requirements  into  major  systems  contracts  in  accordance  with  FAR  Subpart  46.7 
(reference  (aaa)). 

C2.9.3.8.  Component  Breakout.  The  PM  shall  consider  component  breakout  on  every 
program  and  break  out  components  when  there  are  significant  cost  savings  (inclusive  of 
Government  administrative  costs),  the  technical  or  schedule  risk  of  furmshing  government  items 
to  the  prime  contractor  is  manageable,  and  there  are  no  other  overriding  Government  interests 
(e.g.,  industrial  capability  considerations  or  dependence  on  contractor  logistics  support).  The 
acquisition  strategy  shall  address  component  breakout  and  briefly  justify  the  component  breakout 
strategy  (see  DFARS  Appendix  D  (reference  (bbb))).  It  shall  list  all  components  considered  for 
breakout,  and  provide  a  brief  rationale  (based  on  supporting  analyses  from  a  detailed  component 
breakout  review  (which  shall  not  be  provided  to  the  MDA  unless  specifically  requested))  for 
those  not  selected.  The  PM  shall  provide  the  rationale  for  a  decision  not  to  break  out  any 
components. 

C2.9.4.  Leasing.  The  PM  shall  consider  the  use  of  leasing  in  the  acquisition  of  commercial 
vehicles  and  equipment  whenever  the  PM  determines  that  leasing  of  such  vehicles  is  practicable 
and  efficient.  The  PM  shall  not  enter  into  any  lease  with  a  term  of  18  months  or  more,  or  extend 
or  renew  any  lease  for  a  term  of  1 8  months  or  more,  for  any  vessel,  aircraft,  or  vehicle,  unless  the 
PM  has  considered  all  costs  of  such  a  lease  (including  estimated  termination  liability)  and  has 
determined,  in  writing,  that  the  lease  is  in  die  best  interest  of  the  Government.  (10  U.S.C.  2401a 
(reference  (ccc))) 
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C3.  CHAPTERS 
TEST  AND  EVALUATION 


C3.1.  TEST  AND  EVALUATION  (T&E)  OVERVIEW 

C3.1.1.  T&E  reveals  information  about  the  program  and  measures  performance  of  the 
system  against  established  requirements.  The  PM,  in  concert  with  the  user  and  test  communities, 
shall  coordinate  developmental  test  and  evaluation  (DT&E),  operational  test  and  evaluation 
(OT&E),  LFT&E,  family-of-systems  interoperability  testing,  and  modeling  and  simulation 
(M&S)  activities,  into  an  efficient  continuum,  closely  integrated  with  requirements  definition 
and  systems  design  and  development.  The  T&E  strategy  shall  provide  information  about  risk 
and  risk  mitigation,  provide  empirical  data  to  validate  models  and  simulations,  evaluate  techmcal 
performance  and  system  maturity,  and  determine  whether  systems  are  operationally  effective, 
suitable,  and  survivable  against  the  threat  detailed  in  the  System  Threat  Assessment  (see  section 
C6.2.4.).  The  T&E  strategy  shall  also  address  development  and  assessment  of  the  weapons 
support  test  systems  during  the  System  Development  and  Demonstration  Phase,  and  into 
production,  to  ensure  satisfactory  test  system  measurement  performance,  calibration  traceability 
and  support,  required  diagnostics,  safety,  and  correct  test  requirements  implementation. 

Adequate  time  and  resources  shall  be  planned  to  support  pre-test  predictions  and  post-test 
reconciliation  of  models  and  test  results,  for  all  major  test  events. 

C3.1.2.  The  PM  shall  design  DT&E  objectives  appropriate  to  each  phase  and  milestone  of 
an  acquisition  program.  The  OTA  shall  design  OT&E  objectives  appropriate  to  each  phase  and 
milestone  of  a  program,  and  submit  them  to  the  PM  for  inclusion  in  the  Test  and  Evaluation 
Master  Plan  (TEMP).  Completed  lOT&E  and  completed  LFT&E  shall  support  a  beyond  LRIP 
decision  for  ACAT  I  and  II  programs  for  conventional  weapons  systems  designed  for  use  in 
combat.  For  this  purpose,  OT&E  shall  require  more  than  an  operational  assessment  (OA)  based 
exclusively  on  computer  modeling,  simulation,  or  an  analysis  of  system  requirements, 
engineering  proposals,  design  specifications,  or  any  other  information  contained  in  program 
documents.  (10  U.S.C.  2399  (reference  (ddd))  and  10  U.S.C.  2366  (reference  (w))) 

C3.2.  T&E  STRATEGY 

T&E  planning  shall  begin  during  the  Concept  and  Technology  Development  Phase.  The  PM 
shall  form  the  T&E  WIPT.  Representatives  from  DT&E  (contractor  and  government),  OT&E, 
LFT&E,  and  intelligence  communities  shall  support  the  WIPT.  If  a  project  or  program  enters  the 
acquisition  process  later  than  concept  and  technology  development,  the  PM  shall  form  the  WIPT 
prior  to  entering  the  acquisition  process.  A  T&E  WIPT  can  be  useful  for  a  pre-system 
acquisition  activity  (e.g.,  an  advanced  concept  technology  demonstration,  an  advanced 
technology  demonstration,  or  joint  war  fighting  experimentation)  that  has  a  likelihood  of 
becoming  an  acquisition  program.  A  continuous  T&E  WIPT  can  help  ensure  a  smooth 
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transition,  and  can  be  used  to  prepare  the  initial  TEMP.  The  early  integration  of  T&E  with 
program  management  ensures  a  test  strategy  consistent  with  and  supportive  of  the  acquisition 
strategy. 

C3.2.1.  Evaluation  Strategy 

C3.2.1.1.  Projects  that  undergo  a  Milestone  A  decision  shall  have  an  evaluation 
strategy.  Immediately  upon  forming,  the  T&E  WIPT  shall  craft  an  evaluation  strategy  to  support 
pre-acquisition  and  early  acquisition  process  activity.  The  evaluation  strategy  shall  primarily 
address  M&S,  including  identifying  and  managing  the  associated  risk,  and  early  T&E  strategy  to 
evaluate  system  concepts  against  mission  requirements.  Pre-Milestone  A  projects  will  not  have 
an  ORD  nor  Critical  Operational  Issues  (COIs),  on  which  to  base  a  detailed  T&E  plan. 

Therefore,  the  evaluation  strategy  shall  rely  on  the  Mission  Needs  Statement  (MNS)  as  its  basis. 

C3.2.1.2.  The  evaluation  strategy  has  no  mandatory  format.  It  shall  follow  the  same 
approval  process  as  prescribed  for  a  TEMP.  The  strategy  is  due  to  the  Office  of  the  Secretary  of 
Defense  (OSD)  (or  to  the  MDA  for  less  than  ACAT  I,  lA,  or  non-OSD  T&E  oversight  programs) 
not  later  than  180  days  after  the  Milestone  A  decision  or  the  date  the  program  enters  the 
acquisition  cycle.  For  programs  entering  the  acquisition  cycle  at  Milestone  B  or  beyond,  a 
TEMP  shall  be  required  in  lieu  of  the  evaluation  strategy.  The  evaluation  strategy  shall  be  the 
basis  of  and  evolve  into  the  T&E  strategy  in  the  TEMP. 

C3.2.2.  Evolutionary  Acquisition  Consideration.  The  T&E  strategy  for  a  pro^am  using  an 
evolutionary  acquisition  strategy  shall  remain  consistent  with  the  time-phased  requirements  in 
the  ORD.  Test  planning  shall  acknowledge  the  block  deliveries  established  in  the  acquisition 
strategy  and  baselined  in  the  APB.  Test  criteria  shall  be  specific  to  each  increment  of  the 
militarily-useful  capability  planned  for  each  block. 

C3.2.3.  T&E  Planning 
C3.2.3.1.  TEMP 

C3.2.3.1.1.  The  PM  and  T&E  WIPT  shall  produce  a  TEMP  in  support  of 
Milestones  B  and  C.  They  shall  update  the  TEMP  at  the  Full  Rate  Production  Decision  Review 
to  reflect  planning  for  block  upgrades.  The  TEMP  shall  focus  on  the  overall  stracture,  major 
elements,  and  objectives  of  the  T&E  program  and  be  consistent  with  the  acquisition  strategy, 
approved  ORD,  and  C4ISP.  (See  section  C6.4.  and  Appendix  5)  It  shall  provide  a  road  map  for 
integrated  simulation,  test,  and  evaluation  plans,  schedules,  and  resource  requirements  necessary 
to  accomplish  the  T&E  program.  It  shall  mclude  sufficient  detail  to  permit  planning  for  the 
timely  availability  of  the  test  resources  required  to  support  the  T&E  program. 
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C3 .2.3. 1.2.  DOT&E  and  the  cognizant  OIPT  leader  shall  approve  die  TEMP  and 
T&E  portions  of  integrated  program  management  documents  for  all  AC  AT  I  programs,  selected 
ACAT  lAM  programs,  and  other  designated  programs.  Mandatory  TEMP  format  and 
procedures  appear  in  Appendix  2.  This  format  may  be  used  at  the  discretion  of  the  MDA  for 
ACAT  II  and  III  programs  and  highly  sensitive  classified  programs. 

C3.2.3.2.  T&E  Guidelines 

C3 .2.3.2. 1.  Early  T&E  activities  shall  harmonize  MOEs,  MOPs,  and  risk  with  the 
needs  depicted  in  the  MNS,  and  with  the  objectives  and  thresholds  addressed  in  the  analysis  of 
alternatives,  and  defined  in  the  ORD,  APB,  and  TEMP,  as  these  documents  become  available. 
The  user  shall  establish  quantitative  criteria  for  as  many  MOEs  and  MOPs  as  practical.  The 
TEMP  shall  contain  test  event  or  scenario  descriptions  and  resoixrce  requirements  (including 
special  instrumentation,  test  articles,  ranges  and  facilities,  and  threat  targets  and  simulations 
validated  in  accordance  with  a  DOT&E-approved  process)  and  test  limitations  that  impact  the 
system  evaluation.  The  Defense  Intelligence  Agency  (DIA)  shall  validate  the  threat  information 
associated  with  these  elements  of  the  T&E  process. 

C3.2.3.2.2.  The  following  T&E  guidelines  apply: 

C3.2.3.2.2.1.  Test  planning  shall  consider  the  use  of  ground  test  activities,  to 
include  hardware-in-the-loop  simulation,  prior  to  conducting  full-up,  system-level  testing,  such 
as  flight-testing,  in  realistic  environments. 

C3.2.3.2.2.2.  Plarming,  at  minimum,  shall  address  all  system  components 
(hardware,  software,  and  human  interfaces)  critical  to  achieve  and  demonstrate  contract  technical 
performance  specifications  and  ORD-defined  operational  effectiveness  and  suitability 
requirements. 


C3.2.3.2.2.3.  Phased  criteria,  quantitative  when  possible,  shall  determine 
hardware,  software,  and  system  maturity  and  readiness  to  proceed  through  the  acquisition 
process.  The  various  approved  ORD  KPPs  and  the  MOEs  and  MOPs  used  in  die  analysis  of 
alternatives  and  during  T&E  shall  remain  linked. 

C3.2.3.2.2.4.  Planning  shall  provide  for  completed  DT&E,  OT&E,  and 
LFT&E,  as  required,  before  entering  full-rate  production. 

C3.2.3.2.2.5.  T&E  on  commercial  and  non-developmental  items  shall  ensure 
performance,  operational  effectiveness,  and  operational  suitability  for  the  military  application  in 
the  military  environment,  regardless  of  the  manner  of  procurement.  Test  planning  for  these 
items  shall  recognize  commercial  testing  and  experience,  but  nonetheless  determine  the 
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appropriate  DT&E,  OT&E,  and  LFT&E  needed  to  assure  effective  performance  in  the  intended 
operational  environment. 

C3.2.3.2.2.6.  Test  planning  and  conduct  shall  take  full  advantage  of  existing 
investment  in  DoD  ranges,  facilities,  and  other  resources,  wherever  practical,  unless  otherwise 
justified  in  the  TEMP.  The  DoD  Major  Range  and  Test  Facility  Base  is  maintained  and 
managed  to  support  and  provide  capabilities  for  DoD  acquisition  programs  in  accordance  with 
DoD  Directive  3200.11  (reference  (eee)). 

C3.2.3.2.2.7.  Planning  shall  consider  the  potential  testing  impacts  on  the 
environment  (42  U.S.C.  4321-4370d  and  Executive  Order  (E.O.)  121 14  (references  (fff)  and 
(ggg))). 


C3.2.3.2.2.8.  The  concept  of  early  and  integrated  T&E  shall  emphasize 
prototype  testing  during  system  development  and  demonstration  and  early  OAs  to  identify 
technology  risks  and  provide  operational  user  impacts.  OTAs  shall  maximize  their  involvement 
in  early,  pre-acquisition  activities.  The  goal  of  integrated  T&E  shall  be  to  provide  early 
operational  insights  into  the  developmental  process.  This  early  operational  insight  should  reduce 
the  scope  of  the  integrated  OT&E  thereby  contributing  to  reduced  cycle  time  and  TOC. 

C3.2.3.2.2.9.  Appropriate  use  of  accredited  models  and  simulation  to  support 
DT&E,  OT&E,  and  LFT&E  shall  be  coordinated  through  the  T&E  WIPT. 

C3 .2.3.2.2.10.  Planning  shall  consider  a  combined  DT&E,  OT&E,  and/or 
LFT&E  approach.  The  combined  approach  shall  not  compromise  either  developmental  testing 
(DT)  or  operational  testing  (OT)  objectives.  Planning  shall  provide  for  an  adequate  OT  period 
and  report  generation,  including  the  DOT&E  Beyond  LRIP  Report  prior  to  the  decision 
milestone. 


C3.2.3.2.2.1 1.  DOT&E  and  the  Deputy  Director,  DT&E,  Office  of  Strategic 
and  Tactical  Systems,  Office  of  the  USD(AT&L)  shall  have  full  and  timely  access  to  all 
available  developmental,  operational,  and  live  fire  T&E  information. 

C3.2.3.2.2.12.  All  DoD  MDAPs,  programs  on  the  OSD  T&E  Oversight  list, 
post-acquisition  (legacy)  systems,  and  all  programs  and  systems  that  must  interoperate  with 
them,  are  subject  to  interoperability  evaluations  throughout  their  life  cycles  to  validate  their 
ability  to  support  mission  accomplishment.  At  the  discretion  of  the  USD(AT&L),  ASD(C3I), 
DOT&E,  United  States  Joint  Forces  Command  (USJFCOM),  and  the  Joint  Staff,  they  shall  place 
programs  and  systems  deemed  to  have  significant  interoperability  deficiencies  on  the 
Interoperability  Watch  List.  PMs  for  a  program  on  the  Watch  List  will  be  required  to  undertake 
corrective  actions  to  address  interoperability  deficiencies  in  order  to  be  removed  fi'om  the 
Interoperability  Watch  List. 
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C3.2.3.2.2.12.1.  Programs  on  the  Interoperability  Watch  List  will  provide 
periodic  updates  of  current  status  towards  correcting  identified  deficiencies  to  senior 
representatives  of  USD(AT&L),  ASD(C3I),  DOT&E,  USJFCOM,  and  the  Joint  Staff.  The  PM, 
or  other  cognizant  official,  and  the  responsible  test  organization  (either  developmental  or 
operational),  in  conjunction  with  the  Joint  Interoperability  Test  Command  (JITC),  shall  provide 
these  updates.  These  updates  will  support  an  assessment  as  to  whether  interoperability  issues  are 
being  adequately  addressed,  and  whether  a  status  change  is  warranted  (i.e.,  whether  the  program 
or  system  should  be  removed  fi'om  the  Interoperability  Watch  List,  kept  on  the  Interoperability 
Watch  List,  or  proposed  for  T&E  Oversight).  Staff  members  of  USD(AT&L),  ASD(C3I), 
DOT&E,  USJFCOM,  and  the  Joint  Staff  shall  prepare  Quarterly  reports  summarizing  the 
activities  of  systems  and  programs  on  the  Watch  List. 

C3.2.3.2.2.12.2.  For  systems  on  the  OSD  T&E  Oversight  List,  DOT&E 
shall  provide  assessments  at  early  milestone  reviews  as  to  whether  the  system  under  review  has  a 
viable  plan  to  demonstrate  operational  interoperability. 

C3.2.3.2.2.13.  For  IT  systems,  including  NSS,  with  interoperability 
requirements,  the  JITC  shall  provide  system  interoperability  test  certification  memoranda  to  the 
Director,  Joint  Staff  J-6,  throughout  the  system  life-cycle  and  regardless  of  ACAT.  Based  on 
interoperability  evaluations  and  other  pertinent  factors,  the  Joint  Staff  J-6  will  issue 
interoperability  system  validation  memoranda  to  the  respective  Services,  Agencies,  and 
developmental  and  operational  test  organizations.  The  Joint  Staff  J-6  also  provides 
interoperability  requirements  (CRD  and  ORD)  and  supportability  (C4ISP)  certifications. 

C3.3.  ANNUAL  OSD  T&E  OVERSIGHT  LIST 

DOT&E  and  Director,  Strategic  and  Tactical  Systems  (D,  S&TS)  shall  jointly,  and  in 
consultation  with  the  T&E  executives  of  the  cognizant  DoD  Components,  publish  an  Annual 
OSD  T&E  Oversight  List  of  programs  designated  for  OSD  T&E  oversight.  This  list  shall 
identify  programs  on  developmental  test,  operational  test,  or  live-fire  test  oversight.  Programs 
can  be  on  oversight  for  only  one  of  the  three  areas,  or  for  more  than  one  area.  The  DoD 
memorandum  entitled  “Designation  of  Programs  for  OSD  Test  and  Evaluation  (T&E)  Oversight” 
(reference  (hhh))  contains  the  OSD  T&E  Oversight  List. 

C3.4.  DEVELOPMENTAL  TEST  AND  EVALUATION  tPT&E) 

C3.4.1.  DT&E  shall: 

C3.4.I.I.  Identify  the  technological  capabilities  and  limitations  of  the  alternative 
concepts  and  design  options  under  consideration; 
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C3.4.1.2.  Identify  and  describe  design  technical  risks.  Assist  in  the  design  of  a  system 
at  the  component,  sub-system,  and  system  level  by  reducing  technical  risk  prior  to  transitioning 
to  the  next  level; 

C3.4.1.3.  Stress  the  system  under  test  at  least  to  the  limits  of  the  Operational  Mode 
Summary/Mission  Profile  by  “pushing  the  envelope”  to  ensure  expected  operational  performance 
environments  can  be  satisfied.  For  some  systems  it  may  be  appropriate  to  push  beyond  the 
normal  operating  limits  to  ensure  the  robustness  of  the  design. 

C3.4.1.4.  Address  the  potential  of  satisfying  OT&E  requirements  to  the  best  extent 
possible  by  testing  in  operationally  relevant  environments  (simulated  or  actual),  without 
jeopardizing  DT&E  objectives,  to  reduce  overall  T&E  redundancy  and  costs. 

C3.4.1.5.  Analyze  the  capabilities  and  limitations  of  alternatives  to  support  cost- 
performance  trade-offs; 

C3.4.1.6.  Assess  progress  toward  meeting  KPPs  and  other  ORD  requirements,  COIs, 
mitigating  acquisition  technical  risk,  and  achieving  manufacturing  process  reqiiirements  and 
system  maturity; 

C3.4.1.7.  Assess  technical  progress  and  maturity  against  critical  technical  parameters, 
to  include  interoperability,  documented  in  the  TEMP; 

C3.4.1.8.  Provide  data  and  analytic  support  to  the  decision  process  to  certify  the  system 
ready  for  OT&E; 

C3.4.1.9.  In  the  case  of  IT  systems,  support  the  information  systems  security 
certification  process;  and, 

C3.4.1.10.  Prior  to  full  rate  production,  demonstrate  the  maturity  of  the  production 
process  through  Production  Qualification  Testing  of  LRIP  assets. 

C3.4.2.  D,  S&TS  shall  assess  compliance  with  DT&E  policies  and  procedures  in  this 
Regulation. 

C3.5.  CERTIFICATION  OF  READINESS  FOR  OPERATIONAL  TEST  &  EVALUATION 
tOT&Ei 

The  developing  agencies  (i.e.,  materiel  and  combat  developers)  shall  complete  the  following 
tasks  before  starting  OT&E; 

C3.5.1.  Define  risk  management  measures  and  indicators,  with  associated  thresholds,  to 
address  performance  and  technical  adequacy  of  both  hardware  and  software. 
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C3.5.2.  Establish  the  maturity  criteria  and  performance  exit  criteria  necessary  for 
certification  for  OT&E.  The  PM  shall  document  these  maturity  criteria  and  performance  exit 
criteria  in  the  TEMP. 

C3.5.3.  Support  the  conduct  of  Operational  Test  Readiness  Reviews  (OTRRs). 

C3.5.4.  Review  all  available  interoperability  assessments  (e.g.,  OAs,  JITC  interoperability 
assessments,  and  standards  conformance  reports)  during  OTRRs  to  highlight  potentially  critical 
interoperability  problems  for  assessment  during  OT&E. 

C3.5.5.  Complete  a  mission  impact  analysis  of  unmet  criteria  and  thresholds,  including 
critical  interoperability  problems  to  be  assessed  during  OT&E. 

C3.5.6.  Prepare  and  distribute  to  TEMP  signatories  a  DT&E  report  as  prescribed  below. 

C3.5.7.  Formally  certify  the  system  ready  for  OT&E. 

C3.5.8.  Certify  and  accredit  communications  systems  (see  DoD  Instruction  5200.40 
(reference  (iii))); 

C3.5.9.  Conduct  Environment,  Safety,  and  Occupational  Health  (see  subparagraph 
C5 .2.3 .5. 10.)  review  for  each  test. 

C3.6.  OPERATIONAL  TEST  &  EVALUATION  fOT&Ei 

C3.6. 1 .  OT&E  shall  determine  the  operational  effectiveness  and  suitability  of  a  system 
under  realistic  operational  conditions,  including  combat;  determine  if  the  thresholds  and 
objectives  in  the  approved  ORD  and  the  COIs  have  been  satisfied;  and  assess  impacts  to  combat 
operations.  The  following  procedures  shall  apply: 

C3.6.1.1.  The  DoD  Component  OTA  shall  be  responsible  for  OT&E. 

C3.6.1.2.  OT&E  shall  use  threat  or  threat  representative  forces,  targets,  and  threat 
countermeasures,  validated  by  DIA  or  the  DoD  Component  intelligence  agency,  as  appropriate, 
and  approved  by  DOT&E* .  DOT&E  shall  oversee  threat  target,  threat  simulator,  and  threat 
simulation  acquisitions  and  validation  to  meet  developmental,  operational,  and  live  fire  test  and 
evaluation  needs. 


*  Normally  not  applicable  to  ACAT  lA  programs. 
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C3.6.1.3.  Information  assixrance  testing  shall  be  conducted  on  information  systems  to 
ensure  that  planned  and  implemented  security  measures  satisfy  ORD  and  System  Security 
Authorization  Agreement  (SSAA)  requirements  when  the  system  is  installed  and  operated  in  its 
intended  environment.  The  PM,  OT&E  test  authority,  and  designated  approving  authority  shall 
coordinate  and  determine  the  level  of  risk  associated  with  operating  the  system  and  the  extent  of 
security  testing  required  (see  section  C6.6.).  Any  requirements  to  reconstitute  or  recover 
information  system  capabilities  damaged  by  information  assurance  threat  agents  should  also  be 
tested  during  OT&E. 

C3.6.1.4.  Typical  users  shall  operate  and  maintain  the  system  or  item  under  conditions 
simulating  combat  stress  and  peacetime  conditions. 

C3.6.1.5.  The  independent  OTAs  shall  use  production  or  production  representative 
articles  for  the  dedicated  phase  of  OT&E  that  supports  the  fiill-rate  production  decision  (or  for 
ACAT  LA  or  other  acquisition  programs,  the  deployment  decision). 

C3.6.1.6.  Test  planning  shall  consider  M&S.  OT&E  should  leverage  M&S  used  during 
DT&E  to  improve  its  credibility  and  reduce  M&S  development  time  and  costs.  Whenever 
possible,  an  OA  shall  draw  upon  test  results  with  the  actual  system,  or  subsystem,  or  key 
components  thereof,  or  with  operationally  meaningful  surrogates.  When  actual  testing  is  not 
possible  to  support  an  OA,  such  assessments  may  utilize  computer  modeling  and/or  hardware  in 
the  loop,  simulations  (preferably  with  real  operators  in  the  loop),  or  an  analysis  of  information 
contained  in  key  program  docxunents,  consistent  with  section  C3.1.  above.  The  TEMP  (see 
subparagraph  C3. 2.3.1.)  shall  explain  the  extent  of  M&S  supporting  OT&E. 

C3.6.1.7.  The  OTA  shall  test  and  evaluate  all  hardware  and  software  alterations  that 
materially  change  system  performance  (operational  effectiveness  and  suitability).  This  includes 
system  upgrades  and  changes  to  correct  deficiencies  identified  during  T&E. 

C3.6.1.8.  Naval  vessels,  the  major  systems  integral  to  ship  construction,  and  military 
satellite  programs  t5q)ic£dly  have  development  and  construction  phases  that  extend  over  long 
periods  of  time  and  involve  small  procurement  quantities.  To  facilitate  evaluations  and 
assessments  of  system  performance  (operational  effectiveness  and  suitability),  the  PM  shall 
ensure  the  independent  OTA  is  involved  in  the  monitoring  of  or  participating  in  all  relevant 
testing  to  make  use  of  any/all  relevant  results  to  complete  OAs.  The  OTA  shall  determine  the 
inclusion/exclusion  of  test  data  for  use  during  OAs  and  shall  determine  the  requirement  for  any 
additional  operational  testing  needed  for  effectiveness  and  suitability. 

C3.6.1.9.  OTAs  shall  conduct  an  independent,  dedicated  phase  of  OT&E  before  full- 
rate  production  to  evaluate  operational  effectiveness  and  suitability  as  required  by  10  U.S.C. 
2399  (reference  (ddd))  for  ACAT  I  and  II  programs. 
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C3.6.1. 10.  OTAs  shall  participate  in  early  DT&E  and  M&S  to  provide  operational 
insights  to  the  PM,  requirements  developers,  and  acquisition  decision  makers. 

C3.6.1.11.  For  systems  with  joint  interoperability  requirements,  all  available 
interoperability  assessments  (e.g.,  OAs,  JITC  interoperability  assessments,  standards 
conformance  reports)  should  be  reviewed  dining  the  OTRR  before  conducting  lOT&E. 
Potentially  critical  interoperability  problems  shall  be  highlighted  for  assessment  during  OT&E. 

C3.6.1.12.  OT&E  shall  evaluate  potentially  adverse  electromagnetic  environmental 
effects  (E3)  and  spectrum  supportability  situations.  Operational  testers  shall  use  all  available 
data,  and  shall  review  DD  Form  1494  or  JF-12  to  determine  which  systems  need  field 
assessments. 

C3.6.1.13.  All  weapon.  Command,  Control,  Communications,  Computers,  Intelligence, 
Surveillance,  and  Reconnaissance  (C4ISR),  and  information  programs  that  are  dependent  on 
external  information  sources,  or  that  provide  information  to  other  DoD  systems,  shall  be  assessed 
for  information  assurance.  The  level  of  information  assurance  testing  depends  on  the  system  risk 
and  importance.  Systems  with  the  highest  importance  and  risk  shall  be  subject  to  penetration- 
type  testing  prior  to  the  beyond  LRIP  decision.  Systems  with  minimal  risk  and  importance  shall 
be  subject  to  normal  National  Security  Agency  security  and  developmental  testing,  but  shall  not 
be  subject  to  field  penetration  testing  during  OT&E. 

C3.6.1.14.  OT&E  shall  take  maximum  advantage  of  training  and  exercise  activities  to 
increase  the  realism  and  scope  of  OT  and  reduce  testing  costs. 

C3.6.1.15.  DOT&E  shall  determine  the  quantity  of  articles  procured  for  OT&E  for 
MDAPs;  the  cognizant  OTA  shall  make  this  decision  for  non-MDAPs  (10  U.S.C.  2399 
(reference  (ddd))). 

C3.6.1.16.  The  operational  effectiveness  of  MDAPs  for  large-scale  training  systems 
shall  be  determined  based  on  their  demonstrated  training  effectiveness. 

C3.6.1.17.  Each  DoD  Component  shall  provide  weapons  effectiveness  data  for 
weapons  in  the  acquisition  process  to  DOT&E  for  use  in  the  Joint  Munitions  Effectiveness 
Manuals.  The  DoD  Component  shall  provide  the  data  prior  to  the  weapon  achieving  initial 
operational  capability,  and  shall  prepare  the  data  in  coordination  with  the  Joint  Technical 
Coordinating  Group  for  Munitions  Effectiveness. 

C3 .6. 1 . 1 8.  DOT&E  shall  assess  the  adequacy  of  OT&E  and  LFT&E,  and  evaluate  the 
operational  effectiveness,  suitability,  and  survivability,  as  applicable,  of  systems  under  DOT&E 
oversight. 
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C3.6.2.  OT&E  Plans 

C3.6.2.1.  DoD  Components  shall  brief  DOT&E  on  concepts  for  an  OT&E  or  OA  120 
days  prior  to  start.  They  shall  submit  the  T&E  plan  60  days  prior,  and  shall  report  major 
revisions  as  they  occur.  Test  plans  shall  include  test  objectives;  MOEs,  MOPs,  and  measures  of 
operational  suitability;  planned  operational  scenarios;  threat  representations;  targets;  resources; 
test  limitations;  and  methods  of  data  gathering  and  certification,  reduction,  and  analysis.  The 
detail  of  the  planned  test  events  shall  permit  DOT&E  to  assess  operational  realism. 

C3.6.2.2.  DOT&E  shall  approve,  in  writing,  the  adequacy  of  OT&E  plans  (including 
project  fimding)  for  all  ACAT I  programs,  selected  ACAT  lAM  programs,  and  other  programs 
under  DOT&E  oversight  (identified  on  the  "Designation  of  Programs  for  OSD  Test  and 
Evaluation  (T&E)  Oversight"  memorandum),  prior  to  starting  OT&E  (see  section  C3.3.). 

DOT&E  shall  approve  plans  for  all  OAs  in  OSD  T&E-oversight  programs,  prior  to  execution. 
This  approval  requirement  shall  apply  to  major  revisions,  as  well. 

C3. 6.2.3.  DOT&E-oversight  programs  beyond  TRIP,  shall  require  continued  DOT&E 
test  plan  approval,  monitoring,  and  Follow-On  Operational  Test  and  Evaluation  (FOT&E) 
reporting  to  complete  lOT&E  activity;  to  refine  lOT&E  estimates;  to  verify  correction  of 
deficiencies;  to  evaluate  significant  changes  to  system  design  or  employment;  and  to  evaluate 
whether  or  not  the  system  continues  to  meet  operational  needs  and  retain  operational 
effectiveness  in  a  substantially  new  environment,  as  appropriate. 

C3.6.3.  Use  of  Contractors  in  Support  of  OT&E 

C3.6.3.1.  Per  10  U.S.C.  2399  (reference  (ddd)),  persons  employed  by  the  contractor  for 
the  system  being  developed  may  only  participate  in  OT&E  of  major  defense  acquisition 
programs  to  the  extent  that  is  planned  for  them  to  be  involved  in  the  operation,  maintenance,  and 
other  support  of  the  system  when  deployed  in  combat. 

C3.6.3.2.  A  contractor  that  has  participated  (or  is  participating)  in  the  development, 
production,  or  testing  of  a  system  for  a  DoD  Component  (or  for  another  contractor  of  the 
Department  of  Defense)  may  not  be  involved  in  any  way  in  establishing  criteria  for  data 
collection,  performance  assessment,  or  evaluation  activities  for  OT&E.  DOT&E  may  waive 
such  limitation  if  DOT&E  determines  in  writing  that  sufficient  steps  have  been  taken  to  ensure 
the  impartiality  of  the  contractor  in  providing  the  services.  These  limitations  do  not  apply  to  a 
contractor  that  has  participated  in  such  development,  production,  or  testing,  solely  in  test  or  test 
support  on  behalf  of  the  Department  of  Defense. 
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C3.7.  ANTI-TAMPER  VERIFICATION  TESTING 

Anti-tamper  component-level  verification  testing  shall  take  place  prior  to  production  as  a 
function  of  DT/OT.  Component-level  testing  shall  not  assess  the  strength  of  the  anti-tamper 
provided,  but  instead  verify  that  anti-tamper  performs  as  specified  by  the  source  contractor  or 
government  agency. 

C3.8.  LIVE  FIRE  TEST  AND  EVALUATION  tLFT&El^ 

C3.8.1.  10  U.S.C.  2366  (reference  (w))  mandates  LFT&E  for  all  covered  systems.  The 
term  “covered  system”  is  the  DoD  term  that  is  intended  to  include  all  categories  of  systems  or 
programs  identified  in  reference  (w)  as  requiring  LFT&E,  along  with  additional  systems  or 
programs  as  further  described  below  (see  Appendix  3): 

C3.8.2.  The  term  “covered  system”  means  a  system  that  DOT&E,  acting  for  the  Secretary 
of  Defense,  has  determined  to  be: 

C3.8.2.1.  A  major  system  within  the  meaning  of  that  term  in  10  U.S.C.  2302(5) 
(reference  (jjj))  that  is  — 

C3. 8.2. 1.1.  User-occupied  and  designed  to  provide  some  degree  of  protection  to  its 
occupants  in  combat;  or 

C3. 8.2. 1.2.  A  conventional  munitions  program  or  missile  program;  or 

C3. 8.2.2.  A  conventional  munitions  program  for  which  more  than  1,000,000  rounds  are 
planned  to  be  acquired;  or 

C3. 8.2.3.  A  modification  to  a  covered  system  that  is  likely  to  affect  significantly  the 
survivability  or  lethality  of  such  a  system. 

C3.8.3.  Directed  energy  weapons  (DEWs)  are  considered  conventional  (i.e.,  not  nuclear, 
biological,  or  chemical)  for  the  purpose  of  applying  the  law  and  this  Regulation.  LFT&E 
addresses  the  lethality  of  U.S.  DEWs,  and  the  vulnerability  of  U.S.  systems  to  threat  DEWs. 

C3.8.4.  Systems  or  programs  without  decision  points  mentioned  in  10  U.S.C.  2366 
(reference  (w)),  but  otherwise  meeting  statutory  criteria,  shall  be  considered  covered  systems  for 
LFT&E  planning  purposes.  USD(AT&L)  shall  identify  equivalent  acquisition  events  for  such 
systems  or  programs;  and  the  PM  shall  schedule  LFT&E  accordingly.  In  general.  Milestone  B 


^  Not  applicable  to  ACAT  lA  programs. 
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shall  correspond  to  the  point  at  which  a  system  or  program,  in  terms  of  reference  (w),  "enters 
Engineering  and  Manufacturing  Development,"  for  the  purpose  of  applying  the  waiver 
requirements  of  reference  (w).  Pre-acquisition  projects  such  as  advanced  technology 
demonstrations  or  advanced  concept  technology  demonstrations  shall  imdergo  LFT&E  following 
their  transition  into  an  acquisition  program,  if  they  are  a  covered  system.  Commercial  or  non- 
developmental  items  may  be  covered  systems  or  parts  of  covered  systems,  depending  upon  their 
intended  use,  and  shall,  upon  such  determination,  be  subject  to  LFT&E  requirements.  Program 
funding  shall  cover  all  LFT&E  costs. 

C3.8.5.  LFT&E  shall  begin  at  the  component,  subsystem,  and  subassembly  level,  and 
culminate  with  tests  of  the  complete  system,  configured  for  combat.  A  covered  system  shall  not 
proceed  beyond  LRIP  (or  equivalent  point)  until  LFT&E  is  completed  and  the  prescribed 
Congressional  committees  receive  the  required  LFT&E  report  (reference  (w)).  The  PM  shall 
conduct  LFT&E  sufficiently  early  in  the  program  life  cycle  to  allow  time  to  correct  any  design 
deficiency  demonstrated  by  LFT&E.  The  PM  shall  correct  the  design  or  recommend  adjusting 
the  employment  of  the  covered  system  before  proceeding  beyond  LRIP. 

C3.8.6.  DOT&E  shall  approve  the  adequacy  of  the  LFT&E  strategy  before  the  program 
begins  LFT&E.  The  LFT&E  strategy  shall  include  full-up,  system-level  testing  (i.e.,  realistic 
survivability  or  lethality  testing  as  defined  in  reference  (w)),  imless  USD(AT&L)  for  ACAT  ID 
programs,  or  the  CAE  for  less-than  ACAT  ID  programs,  as  delegated  by  the  Secretary  of 
Defense,  waives  such  testing.  Waiver  requests  shall  include  an  alternative  LFT&E  strategy, 
jointly  reviewed  by  DOT&E  and  USD(AT&L),  and  approved  by  DOT&E.  This  alternative 
strategy  shall  include  LFT&E  of  components,  subassemblies,  or  subsystems;  and  appropriate, 
additional,  design  analyses,  M&S,  and  combat  data  analyses.  Following  waiver  approval,  the 
waiver  authority  shall  certify,  in  writing,  to  the  Congressional  defense  committees,  before 
Milestone  B,  or  entry  into  System  Development  and  Demonstration  (or  upon  program  initiation 
if  entering  acquisition  at  system  demonstration  or  later),  that  full-up,  system-level  testing  would 
be  unreasonably  expensive  and  impracticable.  The  certification  is  required  to  be  accompanied 
by  a  report  explaining  how  the  Department  plans  to  evaluate  the  survivability  or  lethality  of  the 
system  or  program  and  assessing  possible  alternatives  to  realistic  survivability  testing  of  the 
system  or  program.  Therefore,  the  waiver  authority  shall  include  the  DOT&E-approved 
alternative  LFT&E  strategy  with  the  certification.  Essentially,  the  certification  shall  explain  how 
USD(AT&L)  or  the  CAE  plans  to  evaluate  the  survivability  or  lethality  of  the  system  or  program 
in  lieu  of  full-up,  system-level  testing.  TEMPs  shall  address  waivers  and  the  use  of  alternative 
LFT&E,  when  applicable.  The  MDA  and  the  DoD  Component  shall  consider  LFT&E  and  the 
LFT&E  waiver  process  when  structuring  programs  and  defining  acquisition  process  entry  points. 

C3.8.7.  Programs  shall  submit  Congressional  certifications  and  reports,  required  by  10 
U.S.C.  2366(c)  (reference  (w)),  through  DOT&E  and  USD(AT&L)  (DoD  Directive  5141.2 
(reference  (kkk))). 
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The  PM  shall  identify  and  fund  required  M&S  resources  early  in  the  acquisition  life  cycle,  so 
that  M&S  may  be  integrated  with  the  T&E  program.  The  PM  shall  use  test  results  to  revise  both 
the  test  program  and  test  procedures.  Test  results  shall  also  be  used  to  develop  and  improve 
models  and  simulations.  The  T&E  WIPT  shall  develop  and  document  a  robust,  comprehensive, 
and  detailed  evaluation  strategy  for  the  TEMP,  using  both  simulation  and  test  resources,  as 
appropriate.  OTAs  shall  develop  evaluation  plans  consistent  with  the  evaluation  strategy. 

C3.10.  FOREIGN  COMPARATIVE  TESTING  (FCT) 

10  U.S.C.  2350a(g)  (reference  (111))  prescribes  funding  for  U.S.  T&E  of  selected  allied 
equipment  and  technologies  when  such  items  and  technologies  have  good  potential  to  satisfy 
valid  DoD  requirements.  USD(AT&L)  shall  centrally  manage  FCT. 

C3.ll.  T&E  REPORTING 

Consistent  with  departmental  policy,  the  MDA  shall  minimize  T&E  reporting  requirements 
consistent  with  statute  and  prudent  T&E  management.  USD(AT&L)  and  DOT&E  shall  have 
access  to  test  data  as  testing  progresses. 

C3. 1 1 . 1 .  DoD  Component  Reporting  of  Test  Results 

C3 . 1 1 . 1 . 1 .  ACAT  I,  selected  ACAT  lAM  programs,  and  other  programs  designated  for 
OSD  T&E  oversight  shall  provide  formal,  detailed,  reports  of  results,  conclusions,  and 
recommendations  from  DT&E,  OT&E,  and  LFT&E  to  DOT&E  and  USD(AT&L)  (or  ASD(C3I), 
as  appropriate).  For  those  reports  supporting  a  decision  point,  the  report  shall  generally  be 
submitted  45  days  before  the  decision  point. 

C3.11.1.2.  All  developmental  and  operational  T&E  agencies  shall  identify  test  and 
evaluation  limitations.  They  shall  report  their  assessment  of  the  effect  of  these  Imutations  on 
system  performance,  and  on  their  ability  to  assess  technical  performance  for  DT&E  or  ORD 
requirements  for  OT&E. 

C3.11.2.  LFT&E  Report^  The  Secretary  of  Defense  (or  DOT&E  if  so  delegated)  shall 
approve  and  submit  a  written  LFT&E  report  to  Congress  before  a  covered  system  proceeds 
beyond  LRIP  (10  U.S.C.  2366  (reference  (w))).  DOT&E  shall  monitor  and  review  LFT&E  of 


^  Not  applicable  to  ACAT  lA  programs. 
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each  covered  system.  At  the  conclusion  of  LFT&E,  the  Director  shall  prepare  an  independent 
assessment  report  describing  the  results  of  the  survivability  or  lethality  LFT&E  and  state  whether 
LFT&E  was  adequate  to  provide  information  to  decision-makers  on  potential  user  casualties  and 
system  vulnerability  or  lethality  when  the  system  is  employed  in  combat;  and  to  ensure  that 
knowledge  of  user  casualties  and  system  vulnerabilities  or  lethality  is  based  on  realistic  testing, 
considering  the  validated  operational  requirements  of  the  system,  the  expected  threat,  and 
susceptibility  to  attack.  DOT&E  shall  prepare  the  OSD  LFT&E  Report  within  45  days  after 
receiving  the  DoD  Component  LFT&E  Report. 

C3. 1 1 .3 .  Beyond-Low  Rate  Initial  Production  (LRIP)  Report^ 

C3. 11.3.1.  DOT&E  shall  analyze  the  results  of  lOT&E  conducted  for  each  MDAP.  At 
the  conclusion  of  lOT&E,  the  Director  shall  prepare  a  report  stating  the  opinion  of  the  Director 
as  to: 


C3.1 1.3.I.I.  Whether  the  T&E  performed  were  adequate;  and 

C3.1 1.3.I.2.  Whether  the  results  of  such  T&E  confirm  that  the  items  or 
components  actually  tested  are  effective  and  suitable  for  combat. 

C3.1 1.3.2.  The  Director  shall  submit  Beyond-LRIP  reports  to  the  Secretary  of  Defense, 
USD(AT&L),  and  the  congressional  defense  committees.  Each  such  report  shall  be  submitted  to 
those  committees  in  precisely  the  same  form  and  with  precisely  the  same  content  as  the  report 
originally  was  submitted  to  the  Secretary  and  USD(AT&L)  and  shall  be  accompanied  by  such 
comments  as  the  Secretary  may  wish  to  make  on  the  report.  A  final  decision  within  the  DoD  to 
proceed  with  a  MDAP  beyond  LRIP  may  not  be  made  until  the  Director  has  submitted  to  the 
Secretary  of  Defense  the  Beyond-LRIP  Report  with  respect  to  that  program  and  the 
congressional  defense  committees  have  received  that  report  (10  U.S.C.  2399  (reference  (ddd))). 
If  the  report  indicates  that  either  OT&E  was  inadequate  or  that  the  system  as  tested  was 
ineffective  or  unsuitable,  DOT&E  shall  continue  to  report  his  or  her  assessment  of  test  adequacy 
and  system  operational  effectiveness  and  suitability,  based  on  FOT&E,  in  the  DOT&E  Annual 
Report. 

C3.1 1.4.  DOT&E  Annual  Report^  DOT&E  shall  prepare  an  annual  OT&E  and  LFT&E 
activities  report,  in  both  classified  and  unclassified  form,  summarizing  all  OT&E  and  LFT&E 
activities,  and  addressing  the  adequacy  of  test  resources  within  DoD  during  the  previous  fiscal 


^  Not  applicable  to  ACAT  lA  programs. 
^  Not  applicable  to  ACAT  lA  programs. 
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year  (10  U.S.C.  139  (reference  (minm))).  The  report  shall  include  the  status  of  information 
assurance,  E3,  and  interoperability  for  each  program.  DOT&E  shall  submit  the  reports 
concurrently  to  the  Secretary  of  Defense,  USD(AT&L),  and  Congress,  within  10  days  of  the 
President's  Budget  to  Congress. 

C3.1 1 .5.  FCT  Notification^.  USD(AT&L)  shall  notify  the  Speaker  of  the  House,  the 
President  of  the  Senate,  the  House  Armed  Services  Committee,  the  Senate  Armed  Services 
Committee,  and  the  Appropriations  Committees  of  the  Senate  and  the  House  of  Representatives 
at  least  30  days  prior  to  committing  funds  to  start  a  new  FCT  evaluation  (10  U.S.C.  2350a(g) 
(reference  (111))). 

C3.11.6.  Report  to  Congress.  USD(AT&L),  as  delegated  by  the  Secretary  of  Defense,  shall 
include  the  following  information  in  a  biennial  report  to  Congress,  as  required  by  10  U.S.C. 
2457(d)  (reference  (nnn)): 

C3.1 1.6.1.  Results  of  each  specific  assessment  and  evaluation  of  the  costs  and  possible 
loss  of  nonnuclear  combat  effectiveness  caused  by  the  failure  to  standardize  equipment  within 
NATO. 


C3 . 1 1 .6.2.  Identification  of  areas  in  which  cooperative  agreements  may  be  made  with 
members  of  NATO. 

C3. 11.6.3.  The  non-developmental  equipment,  software,  munitions,  and  technologies 
of  other  members  of  NATO  evaluated  under  10  U.S.C.  2350a(g)  (reference  (111))  and 

C3.1 1.6.3. 1.  Developed  by  allies  of  the  United  States  and  other  fiiendly  countries 
that  completed  T&E  against  Service  requirements  during  the  previous  fiscal  year; 

C3.1 1.6.3.2.  Procured  by  the  Services  during  the  previous  fiscal  year  as  a  result  of 
successful  T&E;  and, 

C3.1 1.6.3.3.  Selected  to  initiate  and/or  continue  evaluation  in  the  current  fiscal 

year. 


C3.1 1.6.4.  Procurement  actions  initiated  on  each  new  major  system  not  complying  with 
the  policy  of  10  U.S.C.  2457  (reference  (nnn)). 


®  Not  applicable  to  ACAT  lA  programs. 
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C3. 1 1 .6.5.  Procurement  action  initiated  on  each  new  major  system  that  is  not 
standardized  or  interoperable  with  equipment  of  other  members  of  NATO,  including  a 
description  of  the  system  chosen  and  the  reason  for  choosing  that  system. 

C3. 1 1 .6.6.  Identification  of  research  and  development  programs  that  support  or 
conform  to  common  NATO  requirements. 

C3. 1 1.6.7.  Identification  of  common  NATO  military  requirements,  and  action  and 
efforts  to  determine  common  requirements;  and 

C3. 11.6.8.  The  obligation  of  any  funds  under  reference  (111)  for  T&E  of  NATO- 
member  non-developmental  items  during  the  previous  fiscal  year. 

C3.1 1.7.  Electronic  Warfare  (EW)  T«&E  Report.  Pub.  L.  103-160  (1993)  (reference  (ooo)) 
requires  the  Secretary  of  Defense  to  develop  a  DoD  T&E  Process  for  EW  Systems  and  to  report 
annually  on  the  progress  toward  meeting  this  process.  DoD  memorandum,  “Designation  of 
Programs  for  OSD  Test  and  Evaluation  (T&E)  Oversight”  promulgates  the  reporting  procedure, 
the  list  of  EW  programs  required  to  report,  and  report  format.  Designated  programs  shall  submit 
a  one-page  status  report,  through  Service  channels,  to  the  Deputy  Director,  DT&E,  Office  of 
Strategic  and  Tactical  Systems,  Office  of  the  USD(AT&L),  by  November  15th  of  each  year. 
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C4.  CHAPTER  4 

LIFE-CYCLE  RESOURCE  ESTIMATES 


C4.1.  GENERAL 

The  Department  shall  consider  the  TOC  of  each  acquisition  program.  For  purposes  of 
compliance  with  this  Chapter  and  reporting  costs  in  acquisition  documents  (e.g.,  the  APB  and 
Selected  Acquisition  Report  (SAR)),  however,  use  life-cycle  costs  as  defined  in  DoD  5000.4-M 
(reference  (j)). 

C4.2.  ANALYSIS  OF  MULTIPLE  CONCEPTS 


Each  identified  mission  need  has  many  possible  concepts  that  will  satisfy  that  need.  Not  all 
possible  concepts  can  be  explored  in  Concept  Exploration.  The  analysis  of  multiple  concepts  is  a 
process  of  looking  at  possible  concepts  and  identifying  those  concepts  that  could  not  realistically 
satisfy  the  need  at  a  cost  and  on  a  schedule  that  are  acceptable  to  the  user.  The  analysis  of 
multiple  concepts  will  aid  decision-makers  in  placing  appropriate  boundaries  on  the  t3q)e  of 
concepts  to  explore. 

C4.2. 1 .  The  analysis  shall  broadly  examine  each  possible  concept  and  describe  the  rationale 
for  continuing  interest  in  the  concept  or  eliminating  the  concept  from  further  consideration.  The 
intent  of  the  analysis  shall  be  to  define  any  limitations  on  the  type  of  alternatives  the  Department 
of  Defense  will  consider,  while  leaving  the  range  of  remaining  alternatives  as  broad  as  possible, 
so  as  not  to  constrain  innovation  or  creativity  on  the  part  of  industry. 

C4.2.2.  The  DoD  Component(s)  responding  to  a  mission  need  likely  to  result  in  an  ACAT I 
or  LA  program  shall  prepare  the  analysis  of  multiple  concepts.  The  OIPT  Leader  shall  review  the 
analysis,  in  coordination  with  Program  Analysis  and  Evaluation  (PA&E)  and  other  interested 
staff  offices,  and  provide  an  assessment  to  the  MDA. 

C4.3.  ANALYSIS  OF  ALTERNATIVES 


Analyzing  alternatives  is  part  of  the  CATV  process.  Alternatives  analysis  shall  broadly  examine 
multiple  elements  of  project  or  program  alternatives  including  technical  risk  and  matunty,  and 
costs. 

C4.3.1.  The  analysis  shall  be  quantitative,  and  induce  decision  makers  and  staffs  at  all 
levels  to  engage  in  qualitative  discussions  of  key  assumptions  and  variables,  develop  better 
program  imderstanding,  and  foster  joint  ownersWp  of  the  program  and  program  decisions.  There 
shall  be  a  clear  linkage  between  the  analysis  of  alternatives,  system  requirements,  and  T&E 
MOEs  (Pub.  L.  104-106  (1996),  Section  5123  (reference  (e))  and  44  U.S.C.  3506  (reference 
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(c))).  The  analysis  shall  reveal  insights  into  the  program  knowns  and  unknowns,  and  highlight 
relative  advantages  and  disadvantages  of  the  alternatives  being  considered.  The  activity 
conducting  the  analysis  shall  document  its  findings. 

C4.3.2.  The  analysis  shall  include  sensitivity  analyses  to  possible  changes  in  key 
assumptions  (e.g.,  threat)  or  variables  (e.g.,  selected  performance  capabilities).  The  analysis 
shall  explicitly  consider  continued  operating  and  support  costs  of  the  baseline.  Where 
appropriate,  the  analysis  shall  address  the  interoperability  and  commonality  of  components  or 
systems  that  are  similar  in  fimction  to  other  DoD  Component  programs  or  Allied  programs  (see 
10  U.S.C.  2457  (reference  (nnn))).  For  each  alternative,  the  analysis  of  alternatives  shall 
consider  requirements  for  a  new  or  modified  IT,  including  a  NSS,  or  support  infrastructure. 

C4.3.3.  The  analysis  shall  aid  decision-makers  in  judging  whether  any  of  the  proposed 
alternatives  to  an  existing  system  offers  sufficient  military  and/or  economic  benefit  to  justify  the 
cost.  For  most  systems,  the  analysis  shall  consider  and  baseline  against  the  system(s)  that  the 
acquisition  program  will  replace,  if  they  exist.  The  analysis  shall  consider  the  benefits  and 
detriments,  if  any,  of  accelerated  and  delayed  introduction  of  military  capabilities,  including  the 
effect  on  life-cycle  costs.  PA&E  shall  assess  the  analysis  of  alternatives  in  terms  of  its 
comprehensiveness,  objectivity,  and  compliance  with  the  Clinger-Cohen  Act  (reference  (ppp)). 
PA&E  shall  provide  the  assessment  to  the  DoD  Component  head  or  Principal  Staff  Assistant 
(PSA),  and  to  the  MDA.  The  PM  and  MDA  shall  consider  the  analysis,  the  PA&E  assessment, 
and  ensuing  documentation  at  Milestone  B  (or  C,  if  there  is  no  Milestone  B)  for  ACAT  I  and  LA 
programs. 

C4.3.4.  Preparation  Responsibilities 

C4.3.4. 1 .  The  DoD  Component,  or  for  ACAT  LA  programs,  the  office  of  PSA, 
responsible  for  the  mission  area  associated  with  the  mission  deficiency  or  techmcal  opportunity 
normally  prepares  the  analysis  of  alternatives.  The  Plead  of  the  DoD  Component  (or  PSA  for 
ACAT  LA  programs),  or  as  delegated,  but  not  the  PM,  shall  determine  the  independent  activity  to 
conduct  the  analysis.  If  an  analysis  of  alternatives  LPT  forms,  the  PM  or  designated 
representative  may  be  a  team  member,  but  shall  not  be  the  LPT  leader. 

C4. 3.4.2.  The  lead  DoD  Component  for  a  joint  program  shall  ensure  a  comprehensive 
analysis.  If  DoD  Components  supplement  the  lead  Component's  analysis,  the  lead  Component 
shall  ensure  consistent  assumptions  and  methodologies  between  the  analyses. 

C4.3.4.3.  For  ACAT  ID  and  ACAT  LAM  programs,  the  LLead  of  the  DoD  Component, 
PSA,  or  delegated  official  shall  coordinate  with  the  following  offices  early  in  the  development  of 
alternatives:  USD(AT&L)  or  ASD(C31),  Joint  Staff  or  PSA  office,  DOT&E,  and  Director, 

PA&E. 
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C4.3.4.4.  Coordination  shall  ensure  consideration  of  the  full  range  of  alternatives;  the 
development  of  organizational  and  operational  plans,  with  inputs  from  the  Commanders  in  Chief 
of  the  Combatant  Commands,  that  are  consistent  with  U.S.  military  strategy;  and  the 
consideration  of  joint-service  issues,  such  as  interoperability,  security,  and  common  use. 
USD(AT&L)  shall  issue  guidance  for  ACAT  ID  programs.  USD(AT&L)  or  ASD(C3I)  shall 
issue  guidance  for  other  programs.  The  Director,  PA&E  shall  prepare  the  guidance  in 
coordination  with  the  offices  listed  above. 

C4.3.5.  Program  Decision  Points.  Normally,  the  DoD  Component  completes  the  analysis 
and  documents  its  findings  in  preparation  for  a  program  initiation  decision.  The  MDA  may 
direct  updates  to  the  analysis  for  subsequent  decision  points,  if  conditions  warrant.  For  example, 
an  analysis  of  alternatives  may  be  useful  in  examining  cost  performance  trades  at  the  system 
demonstration  interim  progress  review.  An  analysis  of  alternatives  is  imlikely  to  be  required  for 
Milestone  C,  unless  there  was  no  Milestone  B;  unless  the  program  or  circumstances  (e.g.,  threat, 
alliances,  operating  areas,  technology)  changed  significantly;  or  unless  there  are  competing 
procurement  strategies  for  the  same  system.  For  ACAT  LA  programs,  the  PM  shall  incorporate 
the  analysis  of  alternatives  into  the  cost/benefit  element  structure  and  process  described  in 
C4.5.2. 

C4.4.  AFFORDABILITY 

Affordability  is  the  degree  to  which  the  life-cycle  cost  of  an  acquisition  program  is  in 
consonance  with  the  long-range  investment  and  force  structure  plans  of  the  Department  of 
Defense  or  individual  DoD  Components.  The  following  procedures  establish  the  basis  for 
fostering  greater  program  stability  through  the  assessment  of  program  affordability  and  the 
determination  of  affordability  constraints: 

C4.4. 1 .  Components  shall  plan  programs  consistent  with  the  DoD  Strategic  Plan,  and  based 
on  realistic  projections  of  likely  funding  available  in  the  Future  Years  Defense  Program  (FYDP) 
and  in  years  beyond  the  FYDP. 

C4.4.2.  DoD  Component  sponsors  shall  emphasize  affordability  early  in  the  proposed 
program.  The  ORD  (CJCS  Instruction  3 170.01B  (reference  (f)))  shall  address  cost. 

C4.4.3.  The  MDA  shall  assess  affordability  at  each  decision  point.  No  acquisition  program 
shall  proceed  into  System  Development  and  Demonstration  unless  sufficient  resources,  including 
manpower,  are  programmed  in  the  most  recently  approved  FYDP,  or  will  be  programmed  in  the 
next  Program  Objective  Memorandum  (POM),  Budget  Estimate  Submission  (BES),  or 
President’s  Budget  (Pub.  L.  104-106  (1996)  (reference  (qqq))  and  0MB  Circular  A-11  (reference 

(b))). 
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C4.4.4.  Cost  Analysis  Improvement  Group  (CAIG)  (see  section  C7.12.)  reviews  shall 
ensure  that  cost  data  supporting  affordability  judgments  for  ACAT  I  programs  are  accurate.  The 
Cost/Performance  IPT  (see  paragraph  C7.6.6.)  shall  ensure  that  cost  and  benefit  data  supporting 
affordability  judgments  for  ACAT  lA  programs  are  accurate. 

C4.4.5.  The  manpower  estimate  for  the  program  shall  address  manpower  affordability  in 
terms  of  military  end-strength,  civilian  full-time  equivalents,  and  contractor  work  years. 

C4.4.6.  Prior  to  submitting  the  POM  or  BES  to  the  Secretary  of  Defense,  the  Heads  of  the 
DoD  Components  shall  consult  with  USD(AT&L)  or  ASD(C3I),  as  appropriate,  when  the  POM 
or  BES  contains  a  significant  change  in  funding  for,  or  reflects  a  significant  funding  change  in, 
any  program  subject  to  Defense  Acquisition  Board  (DAB)  or  DoD  CIO  review  (DoD  Directive 
5134.1  (reference  (rrr))). 

C4.4.7.  Full  Funding 

C4.4.7.1.  When  the  DAB  or  Information  Technology  Overarching  Integrated  Product 
Team  (IT  OIPT)  (see  paragraph  C7.6.4.)  reviews  a  program,  the  Head  of  the  DoD  Component 
responsible  for  the  program  shall  report  the  fimding  for  the  program,  as  contained  in  the  most 
recent.  Secretary  of  Defense-approved  FYDP,  to  USD(AT&L)  or  ASD(C3I),  as  appropriate. 

The  Head  of  the  DoD  Component  shall  describe  the  best  possible  acquisition  strategy,  given 
currently  approved  program  funding.  If  the  DoD  Component  prefers  a  different  approach,  the 
Head  of  the  DoD  Component  shall  describe  the  DoD  Component  preference,  as  well. 

C4.4.7.2.  If,  after  review,  USD(AT&L)  or  ASD(C3I)  concludes  that  the  FYDP  funding 
for  the  program  will  not  support  the  program  as  presented,  the  Head  of  the  DoD  Component 
shall  commit  to  incorporate  appropriate  funding  in  the  next  FYDP  update. 

C4.5.  RESOURCE  ESTIMATES 


C4.5.1.  The  PM  shall  prepare  a  life-cycle  cost  estimate  (LCCE)  for  all  ACAT  I  program 
initiation  decisions  and  at  all  subsequent  program  decision  points. 

C4.5.1.1.  OSD  CAIG  (see  section  C7.12.)  shall  prepare  an  independent  LCCE  and 
associated  report  for  the  decision  authority  for  all  ACAT  ID  programs,  and  for  ACAT  IC 
programs  as  requested  by  USD(AT&L),  for  all  major  decision  points  as  specified  in  DoD 
Instruction  5000.2,  enclosure  3  (reference  (a)),  or  as  directed  by  the  MDA. 

C4.5.1.2.  The  DoD  Component  cost  agency  shall  prepare  an  independent  LCCE  and 
associated  report  for  the  decision  authority  for  all  ACAT  IC  programs,  except  those  reviewed  by 
the  CAIG,  for  all  major  decision  points  as  specified  in  DoD  Instruction  5000.2,  enclosmre  3 


71 


CHAPTER 4 


DoD  5000.2-R,  June  2001 


(reference  (a)),  or  as  directed  by  the  MDA.  For  programs  with  significant  cost  risk  or  high 
visibility,  the  CAE  may  request  an  additional  DoD  Component  cost  analysis  estimate. 

C4.5.1.3.  For  ACAT I  programs,  the  MDA  shall  consider  the  independent  LCCE 
before  approving  entry  into  system  development  and  demonstration  or  into  production  and 
deployment  (10  U.S.C.  2434  (reference  (sss))). 

C4.5.1.4.  The  DoD  Component’s  manpower  authority  shall  prepare  a  manpower 
estimate  in  support  of  program  initiation  for  ACAT  I  programs.  They  shall  update  the  estimate 
at  subsequent  milestones  and  the  full-rate  production  decision  review.  The  MDA  shall  consider 
the  manpower  estimate  before  approving  entry  into  system  development  and  demonstration  and 
again  before  entry  into  production  and  deployment  (10  U.S.C.  2434  (reference  (sss))). 

C4.5.1.5.  For  ACAT  LA  program  initiation,  the  PM  shall  prepare  a  life-cycle  cost  and 
benefits  estimate,  often  termed  an  economic  analysis  (EA).  The  EA  shall  consist  of  an  LCCE 
and  a  life-cycle  benefits  estimate,  including  a  return  on  investment  (ROI)  calculation  (Pub.  L. 
104-106  (1996),  Section  5123  (reference  (e))).  The  MDA  usually  directs  an  update  to  the  EA 
whenever  program  cost,  schedule,  or  performance  parameters  significantly  deviate  from  the 
approved  APB. 

C4.5. 1 .6.  The  PSA  or  sponsoring  DoD  Component  shall  ensure  that  the  DoD 
Component  also  provides  a  cost  analysis  for  all  ACAT  LA  programs  each  time  an  EA  is  required. 
The  DoD  Component  cost  analysis  is  an  independent  estimate  of  life-cycle  costs.  The  DoD 
Component  may  request  a  sufficiency  review  of  the  program  office  LCCE  in  lieu  of  conducting  a 
full  cost  analysis.  The  MDA  shall  determine  whether  a  sufficiency  review  is  appropriate.  If 
appropriate,  the  Cost  WIPT  shall  establish  the  scope  of  the  sufficiency  review. 

C4.5. 1.6.1.  PA&E  shall  assess  the  EA  to  determine  the  following: 


C4.5. 1 .6. 1 . 1 .  Reasonableness  of  the  life-cycle  cost  and  benefits  estimates; 
C4.5.1.6.1.2.  Whether  the  cost,  schedule,  and  performance  goals  are  realistic; 
C4.5.L6.1.3.  Reliability  of  the  ROI  calculation;  and 
C4.5. 1 .6. 1 .4.  Traceability  of  the  estimated  benefits,  as  presented. 

C4.5 .1.6.2.  PA&E  shall  provide  results  of  the  assessment  to  both  the  PM  and 


MDA. 

C4.5. 1 .6.3.  For  ACAT  LA  programs,  the  MDA  shall  consider  the  DoD  Component 
cost  analysis  and  PA&E  assessment. 
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C4.5.2.  Life-Cycle  Cost  Estimates  (LCCEs) 

C4.5.2.1.  The  estimating  activity  shall  explicitly  base  the  LCCE  (or  EA  for  AC  AT  LA 
programs)  on  program  objectives;  operational  requirements;  contract  specifications;  careful  risk 
assessments;  and,  for  ACAT I  programs,  a  DoD  program  work  breakdown  structure  (WBS),  or, 
for  ACAT  LA  programs,  a  life-cycle  cost  and  benefit  element  structure  agreed  upon  by  the  IPT. 
The  LCCE  (or  EA)  shall  be  comprehensive.  It  shall  identify  all  cost  elements,  including 
operation  and  support  costs,  that  affect  the  decision  to  proceed  with  development  or  production 
of  the  system,  regardless  of  funding  source  or  management  control. 

C4.5.2.2.  The  LCCE  (or  EA  for  ACAT  lA  programs)  shall  be  consistent  with  the  cost 
estimates  in  the  analysis  of  alternatives,  and  shall  explain  major  changes  that  may  have  occurred. 
It  shall  present  a  realistic  appraisal  of  the  level  of  cost  most  likely  to  be  realized.  The  manpower 
estimates  underpiiming  operation  and  support  costs  shall  be  consistent  with  the  manpower 
estimate  of  section  C4.5.4.2.  The  LCCE  for  ACAT  lA  programs  shall  include  life-cycle  benefits 
as  well  as  life-cycle  costs  (Pub.  L.  104-106  (1996),  Section  5123  (reference  (e))  and  44  U.S.C. 
3506  (reference  (c))). 

C4.5.2.3.  For  an  ACAT  LA  program,  the  PM  shall  develop  and  use  the  life-cycle 
benefits  estimate  portion  of  the  EA  to  identify  and  project  both  mission  and  system  benefits. 
Mission  benefits  include  both  quantitative  monetary  benefits,  such  as  reduced  operating  costs;  as 
well  as  non-monetary  benefits,  such  as  improved  efficiency  or  functionality.  System  benefits 
also  include  both  monetary  and  non-monetary  benefits,  such  as  reduced  total  ownership  cost  or 
higher  reliability. 

C4.5.3.  Cost  Analysis  Requirements  Description  (CARD).  For  ACAT  I  programs,  the  DoD 
Component  sponsoring  the  acquisition  shall  establish  a  CARD.  The  PM  shall  prepare,  and  an 
authority  no  lower  than  the  DoD  Component  PEO,  shall  approve  the  CARD.  For  ACAT  LA 
programs,  the  PM  shall  establish  the  CARD  in  coordination  with  appropriate  IPT  members.  The 
CARD  shall  describe  the  salient  features  of  both  the  acquisition  program  and  the  system  itself, 
and  provide  the  basis  for  the  LCCEs.  The  CARD  shall  be  flexible,  tailored,  and  refer  to 
information  available  in  other  documents  available  to  cost  estimators.  For  joint  programs,  the 
CARD  shall  cover  the  common  program  as  agreed  to  by  all  participating  DoD  Components,  as 
well  as  any  unique,  DoD  Component  requirements.  The  teams  preparing  the  program  office 
LCCE,  the  component  cost  analysis,  if  applicable,  and  the  independent  LCCE  shall  receive  the 
CARD  180  days  prior  to  a  planned  OIPT  or  DoD  Component  review,  unless  the  OIPT  leader 
agrees  to  another  due  date. 

C4.5.4.  Manpower.  The  DoD  Components  shall  determine  the  most  efficient  and  cost 
effective  mix  of  government  manpower  and  contract  support  for  all  systems.  The  DoD 
Components  shall  not  contract  for  inherently  governmental  and  exempted  functions. 
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C4.5.4. 1 .  Manpower  Considerations 

C4.5.4. 1.1.  For  all  programs  regardless  of  acquisition  category,  DoD  Components 
shall  determine  the  source  of  support  for  all  new,  modified,  and  replacement  systems  based  on 
the  procedures,  manpower  mix  criteria,  and  risk  assessment  instructions  in  Deputy  Under 
Secretary  of  Defense  (Program  Integration),  Office  of  the  Under  Secretary  of  Defense  (Personnel 
&  Readiness)  (OUSD(P&R)),  and  Deputy  Under  Secretary  of  Defense  (Installations),  Office  of 
USD(AT&L)  aimual  memo,  "DoD  Inventory  of  Commercial  and  Inherently  Governmental 
Activities  Data  Call."  They  shall  consider  the  advantages  of  converting  from  one  soiurce  to 
another  (military,  civilian,  or  private  contract)  (10  U.S.C.  129a  (reference  (ttt))),  and  the  use  of 
inter-service  and  intra-govemmental  support  (DoD  Instruction  4000.19  (reference  (uuu))).  The 
DoD  Components  shall  competitively  source  support  functions  in  accordance  with  DoD 
Directive  4100.15  (reference  (vw))  and  DoD  Instruction  4100.33  (reference  (www)). 

C4.5.4.1.2.  The  DoD  Components  shall  determine  manpower  and  contract  support 
based  on  both  peacetime  and  wartime  requirements,  and  establish  manpower  authorizations  at 
the  minimum  necessary  to  achieve  specific  vital  objectives  (DoD  Directive  1100.4  (reference 
(xxx))).  As  part  of  this  process,  the  DoD  Components  shall  assess  the  risks  (DoD  Instruction 
3020.37  (reference  (yyy)))  involved  in  contracting  support  for  critical  functions  in-theater,  or  in 
other  areas  expecting  hostile  fire.  Risk  mitigation  shall  take  precedence  over  cost  savings  in 
high-risk  situations  or  when  there  are  highly  sensitive  intelligence  or  security  concerns. 

C4.5.4.2.  Manpower  Estimate’ 

C4.5.4.2.1.  The  manpower  estimate  for  ACAT  I  programs  shall  outline  the  DoD 
Component’s  official  manpower  position,  and  address  whether  the  system  is  affordable  from  a 
military  end-strength  and  civilian  full-time  equivalent  (FTE)  perspective.  The  DoD  Component 
shall  base  manpower  numbers  on  the  level  of  system  performance  (e.g.,  reliability  and 
maintainability)  most  likely  to  be  achieved. 

C4.5. 4.2.2.  The  estimate  shall  report  the  total  number  of  manpower  requirements 
and  authorizations  needed  to  operate,  maintain,  support,  and  provide  training  for  the  system  upon 
full  operational  deployment.  It  shall  report  the  number  of  military  (officer,  warrant  officer,  and 
enlisted),  DoD  civilian  manpower,  and  contract  work-years  for  each  fiscal  year  of  the  program, 
beginning  with  initial  fielding  and  ending  with  system  retirement/disposal.  It  shall  indicate  if 
there  are  any  resource  shortfalls  in  any  fiscal  year  covered  by  the  report.  It  shall  state  whether 
any  increases  in  military  end  strengths  or  civilian  FTEs  (beyond  what  is  included  in  the  FYDP) 
or  whether  waiver(s)  to  existing  manpower  constraints  is/are  required  to  support  full  operational 


’  Not  applicable  to  ACAT  lA  programs. 
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deployment  of  the  system.  The  estimate  shall  report  Active,  Reserve,  and  National  Guard 
numbers  separately.  For  joint  programs,  each  DoD  Component  shall  provide  a  separate  estimate. 

C4.5.4.2.3.  The  manpower  estimate  shall  compare  manpower  requirements  of  the 
new  system  against  the  old  or  replaced  system(s),  if  applicable.  It  shall  address  whether  the  new 
system  meets  or  exceeds  manpower  objectives  and  thresholds  in  the  ORD,  if  so  established. 

C4.5.4.2.4.  The  manpower  estimate  shall  address  whether  there  are  any  personnel 
issues  that  would  adversely  impact  fiill  operational  deployment  of  the  system.  It  shall  clearly 
state  the  risks  associated  with  and  the  likelihood  of  achieving  manpower  numbers  reported  in  the 
estimate.  It  shall  briefly  assess  the  validity  of  the  manpower  numbers,  stating  whether  the  DoD 
Component  used  validated  manpower  methodologies  and  manpower  mix  criteria,  and  assessed 
all  risks.  The  estimate  shall  address  whether  planned  or  recently  completed  manpower  and 
personnel  initiatives  (e.g.,  reorganization,  restructuring,  or  reengineering  actions;  or  military 
occupational  specialty  consolidations),  competitive  sourcing  initiatives  (i.e.,  cost  comparisons  or 
direct  conversions),  or  other  actions  could  impact  the  manpower  numbers. 

C4.5.4.2.5.  For  ACAT  ID  programs,  OUSD(P&R)  shall  review  manpower 
estimates  and  provide  comments  to  the  OIPT. 


75 


CHAPTER 4 


DoD  5000.2-R,  June  2001 


C5.  CHAPTERS 
PROGRAM  DESIGN 

C5.1.  INTEGRATED  PRODUCT  AND  PROCESS  DEVELOPMENT  (IPPP) 

The  PM  shall  employ  IPPD  to  the  maximum  extent  practicable.  IPPD  considers  and  integrates 
program  activities  throughout  the  entire  program  life  cycle,  including  systems  management, 
development,  manufacturing,  testing,  deplo3Tnent,  operations,  support,  training,  and  eventual 
disposal.  Using  IPPD,  multi-disciplined  IPTs  shall  simultaneously  optimize  the  product,  product 
manufacturing,  and  supportability  to  meet  system  cost  and  performance  objectives. 

C5.2.  SYSTEMS  ENGINEERING 

C5.2.1.  The  PM  shall  implement  a  sound  systems  engineering  approach  to  translate 
approved  operational  needs  and  requirements  into  operationally  suitable  blocks  of  systems.  The 
approach  shall  consist  of  a  top-down,  iterative  process  of  requirements  analysis,  functional 
analysis  and  allocation,  design  synthesis  and  verification,  and  system  analysis  and  control. 
Systems  engineering  shall  permeate  design,  manufacturing,  T&E,  and  support  of  the  product. 
Systems  engineering  principles  shall  influence  the  balance  between  performance,  risk,  cost,  and 
schedule. 

C5.2.2.  The  systems  engineering  process  shall: 

C5.2.2.1.  Transform  approved  operational  needs  and  requirements  (see  CJCS 
Instruction  3 170.0 IB  (reference  (f)))  into  an  integrated  system  design  solution  through 
concurrent  consideration  of  all  life-cycle  needs  (i.e.,  development,  manufacturing,  T&E, 
deployment,  operations,  support,  training,  and  disposal). 

C5.2.2.2.  Ensure  the  interoperability  and  integration  of  all  operational,  functional,  and 
physical  interfaces.  Ensme  that  system  definition  and  design  reflect  the  requirements  for  all 
system  elements:  hardware,  software,  facilities,  people,  and  data;  and 

C5.2.2.3.  Characterize  and  manage  technical  risks. 

C5. 2.2.4.  Apply  scientific  and  engineering  principles,  using  the  system  security 
engineering  process,  to  identify  security  vulnerabilities  and  minimize  or  contain  information 
assurance  and  force  protection  risks  associated  with  these  vulnerabilities  (see  DoD  5200. 1-M 
(reference  (zzz))). 

C5.2.3.  The  following  key  systems  engineering  activities  shall  occur: 
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C5.2.3.1.  Requirements  Analysis.  The  PM  shall  work  with  the  user  to  establish  and 
refine  operational  and  design  requirements.  Together,  they  shall  determine  appropriate 
operational  performance  objectives,  within  affordability  constraints.  Iterative  requirements 
analyses  shall  accompany  functional  analysis/allocation  to  develop  and  refine  system-level 
functional  and  performance  requirements  and  external  interfaces  to  facilitate  the  design  of  open 
systems.  These  analyses  shall  allocate  and  balance  interoperability  requirements  among  systems 
that  must  interoperate  successfully  to  satisfy  all  appropriate  CRDs  the  proposed  system  falls 
imder.  Anti-tamper  requirements  shall  be  expressly  addressed.  Requirements  analysis  shall 
provide  traceability  among  user  requirements  and  design  requirements. 

C5. 2.3.2.  Functional  Analysis/Allocation.  Iterative  functional  analyses/allocations 
shall  define  successively  lower-level  functional  and  performance  requirements,  including 
functional  interfaces  and  architecture  to  achieve  open  systems  and  facilitate  the  use  of  a  PBBE. 
Functional  and  performance  requirements  shall  track  with  higher-level  requirements.  System 
requirements  shall  be  allocated  and  defined  in  sufficient  detail  to  provide  design  and  verification 
criteria  to  support  the  integrated  system  design.  System  interface  control  requirements  that  are 
developed  shall  be  documented. 

C5.2.3.3.  Design  Synthesis  and  Verification.  Design  synthesis  translates  functional  and 
performance  requirements  into  design  solutions  that  include  alternative  people,  product,  and 
process  concepts  and  solutions,  and  internal  and  external  interfaces.  Design  solutions  shall  be 
sufficiently  detailed  to  verify  that  open  system  performance  requirements  have  been  met.  Design 
verification  shall  include  a  cost-effective  combination  of  design  analysis,  design  M&S,  and 
demonstration  and  testing.  Verification  shall  address  design  tools,  products,  and  processes. 

C5.2.3.4.  System  Analysis  and  Control.  System  analysis  and  control  activities  shall 
provide  the  basis  for  evaluating  and  selecting  alternatives,  measuring  progress,  documenting 
design  decisions,  and  enabling  and  managing  block  deliveries  under  an  evolutionary  acquisition 
strategy.  They  shall  include  the  following: 

C5.2.3.4.1.  Trade-off  studies  among  requirements  (operational,  functional,  and 
performance);  design  alternatives  and  their  related  manufacturing,  testing,  and  support  processes; 
program  schedule;  and  life-cycle  cost;  at  the  appropriate  level  of  detail  to  support  decision 
making  and  lead  to  a  proper  balance  between  performance  and  cost. 

C5.2.3.4.2.  The  overall  risk  management  effort  shall  include  technology  transition 
planning  and  shall  establish  transition  criteria. 

C5.2.3.4.3.  The  establishment  of  a  risk  management  process  (including  planning, 
assessment  (identification  and  analysis),  handling,  and  monitoring)  to  be  integrated  and 
continuously  applied  throughout  the  program,  including,  but  not  limited  to,  the  design  process. 
The  risk  management  effort  shall  address  risk  plaimiug,  the  identification  and  analysis  of 
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potential  sources  of  risks  including  but  not  limited  to  cost,  performance,  and  schedule  risks  based 
on  the  technology  being  used  and  its  related  design,  manufacturing  capabilities,  potential 
industry  sources,  and  test  and  support  processes;  risk  handling  strategies,  and  risk  monitoring 
approaches.  The  overall  risk  management  effort  shall  interface  with  technology  transition 
planning,  including  the  establishment  of  transition  criteria  for  such  technologies. 

C5.2.3.4.4.  The  maximum  use  of  performance  requirements  for  items  identified  as 
high  pay-off  for  technology  insertion. 

C5.2.3.4.5.  A  configuration  management  process  to  guide  the  system  products, 
processes,  and  related  documentation,  and  to  facilitate  the  development  of  open  systems.  The 
configuration  management  effort  includes  identifying,  documenting,  and  auditing  the  functional 
and  physical  characteristics  of  an  item;  recording  the  configuration  of  an  item;  and  controlling 
changes  to  an  item  and  its  documentation.  It  shall  provide  a  complete  audit  trail  of  decisions  and 
design  modifications. 

C5.2.3.4.6.  An  integrated  data  management  system  to  capture  and  control  the 
technical  baseline  (configuration  documentation,  technical  data,  and  technical  manuals);  provide 
data  correlation  and  traceability  among  performance  requirements,  designs,  decisions,  rationale, 
and  other  related  program  planning  and  reporting  elements;  facilitate  technology  insertion  for 
affordability  improvements  during  reprocurement  and  post-production  support;  support 
configuration  procedures;  and  serve  as  a  ready  reference  for  the  systems  engineering  effort. 

C5.2.3.4.7.  Performance  metrics  to  measure  technical  development  and  design, 
actual  versus  planned;  and  to  measure  meeting  system  requirements  in  terms  of  performance, 
cost,  schedule,  and  progress  in  implementing  risk  handling.  Performance  metrics  shall  be 
traceable  to  performance  parameters  identified  by  the  operational  user. 

C5 .2.3. 4.8.  A  verification  (including  test  and  measurement)  effectiveness  review 
process  to  demonstrate  and  confirm  verification  adequacy  and  compliance  with  specified 
requirements. 


C5.2.3.4.9.  Interface  controls  to  ensure  all  internal  and  external  interface 
requirements  changes  are  properly  recorded  and  communicated  to  all  affected  configuration 
items. 


C5.2.3.4.10.  A  structured  review  process  to  demonstrate  and  confirm  completion 
of  required  accomplishments  and  their  exit  criteria  as  defined  in  program  planning.  Overall 
program  planning  shall  include  reviews  to  demonstrate,  confirm,  and  coordinate  progress. 
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C5.2.3.5.  The  following  paragraphs  discuss  other  important  design  considerations. 
Their  impact  on  total  system  cost,  schedule,  and  performance  shall  determine  the  extent  of  their 
consideration  during,  and  their  affect  upon,  the  system  design  process. 

C5.2.3.5.1.  Manufacturing  and  Production^ 

C5 .2.3.5. 1 . 1 .  Producibility  of  the  system  design  shall  be  a  development 
priority.  Design  engineering  efforts  shall  concurrently  develop  producible  designs,  capable 
manufacturing  processes,  and  the  necessary  process  controls  to  satisfy  requirements  and 
minimize  manufacturing  costs.  The  PM  shall  use  existing  manufacturing  processes  whenever 
possible.  When  the  design  requires  new  manufacturing  capabilities,  the  PM  shall  consider 
process  flexibility  (e.g.,  rate  and  configuration  insensitivity). 

C5.2.3.5. 1 .2.  Full  rate  production  of  a  system  shall  require  a  stable  design, 
proven  manufacturing  processes,  and  available  or  programmed  production  facilities  and 
equipment. 


C5.2.3.5.2.  Modeling  &  Simulation  (M&S) 

C5.2.3.5.2.1.  The  PM  shall  judiciously  employ  and  reuse  advanced  M&S  and 
related  technologies.  The  Department  of  Defense  and  industry  shall  collaborate  to  produce 
integration  and  interoperability  capabilities  spanning  all  acquisition  functions  and  phases. 
Expected  results  include  improved  acquisition  program  execution  and  superior  acquired  systems. 

C5.2.3.5.2.2.  PMs  shall  leverage  M&S  and  related  technologies  as  part  of  the 
M&S  approach  supporting  the  acquisition  strategy  and  program  design.  They  shall  properly 
integrate  M&S  and  related  technologies  throughout  systems  acquisition.  They  shall  identify  and 
employ  knowledge  representation  and  commimication  techniques  and  procedures  associated  with 
the  design,  development,  and  life  cycle  of  both  the  program  and  its  system  early  in  and 
throughout  the  program,  as  appropriate. 

C5.2.3.5.2.3.  Planning  the  M&S  Approach 

C5.2.3.5.2.3.1.  The  PM  shall  plan  for  and  document  the  M&S  approach 
as  part  of  the  acquisition  strategy,  and  keep  the  approach  current  throughout  the  program  life 
cycle.  Planning  shall  comply  with  the  DoD  Component  implementing  directives. 

C5.2.3.5.2.3.2.  The  PM  shall  accomplish  the  following: 


^  Not  applicable  to  AC  AT  lA  programs. 
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C5.2.3.5.2.3.2.1 .  Map  M&S  onto  the  design  process  to  identify  the 
core  M&S  development  that  the  contractor  or  DoD  Component  Science  &  Technology  element 
must  address; 


C5.2.3.5.2.3.2.2.  Identify  which  steps  of  tiie  design  process  that  M&S 
will  accomplish  or  facilitate; 

C5.2.3.5.2.3.2.3.  Make  necessary  investments  to  enable  execution  of 
the  M&S  approach,  including  early  identification  of  and  planning  for  required  resources; 

C5.2.3.5.2.3.2.4.  Integrate  M&S  efforts  over  the  life  cycle  of  the 
system,  from  requirements  and  concept  development,  through  engineering,  production,  testing, 
sustainment,  and  post-production  support; 

C5.2.3.5.2.3.2.5.  Relate  M&S  to  other  acquisition  activities  such  as 
Simulation  Test  and  Evaluation  Process,  CAIV,  and  IPPD; 

C5.2. 3.5.2. 3.3.  The  appropriate  Lead  Executive  Component  Executive  or 
Service  Acquisition  Executive  (SAE)  and  T&E  authorities  shall  approve  the  M&S  approach. 

C5.2.3.5.2.4.  M&S  Standards.  M&S  standards  facilitate  reuse,  commonality, 
interoperability,  and  credibility.  Properly  applied,  M&S  standards  reduce  cost  by  providing 
approved  solutions  to  common  problems.  As  part  of  the  M&S  approach  in  the  acquisition 
strategy,  the  PM  shall  identify  and  require  contractors,  where  practicable,  to  use  M&S  standards, 
where  they  exist.  Examples  of  such  standards  encompass  authoritative  algorithms  and  models, 
interoperability  standards  for  simulations  and  command  and  control  systems,  and  data 
interchange  standards. 

C5.2.3.5.2.5.  Relationship  of  M&S  and  Testing.  The  PM  shall  use  both 
testing  and  M&S  to  evaluate  the  performance  and  maturity  of  the  system  under  development.  In 
addition,  the  PM  shall  use  M&S  to  predict  the  results  of  operational  and  live  fire  testing  events 
prior  to  the  conduct  of  those  tests.  The  PM  shall  focus  the  testing  program  on  those  tests  with 
the  highest  expected  payback  in  knowledge  gained.  After  the  tests,  the  DoD  Component  M&S 
offices  shall  use  test  results  to  validate  and  mature  the  M&S  tools  and  databases. 

C5.2.3.5.2.6.  M&S  Support  of  SBA.  Whenever  and  wherever  possible 
throughout  systems  acquisition,  the  PM  shall  make  effective  use  of  M&S  approaches  to  provide 
a  robust  analysis  of  system  performance  to  compliment  hardware-only  T&E.  The  PM  shall  use 
M&S  to  assess  a  system  against  design  to  threats  and  analyze  to  threats  in  those  scenarios  and 
areas  of  the  mission  space  or  performance  envelope  where  testing  cannot  be  performed,  is  not 
cost  effective,  or  additional  data  is  required.  These  analyses  are  performed  using  validated 
M&S,  and  are  supported  by  validated  test  data. 
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C5.2.3.5.3.  Quality 

C5.2.3.5.3.1.  The  quality  management  process  shall  be  capable  of  tiie 
following  key  activities: 


C5.2.3.5.3.1.1. 

C5.2.3.5.3.1.2. 

variation; 

C5.2.3.5.3.1.3. 

feedback;  and 

C5.2.3.5.3.1.4. 

action  system. 

C5.2.3.5.3.1.5. 

Establish  capable  processes; 

Continuously  improve  processes; 

Monitor  and  control  critical  processes  and  product 

Establish  mechanisms  for  field  product  performance 

Implement  an  effective  root-cause  analysis  and  corrective 


C5.2.3.5.3.2.  The  PM  shall  allow  contractors  to  define  and  use  a  preferred 
quality  management  process  that  meets  required  program  support  capabilities.  The  PM  shall  not 
require  third  party  certification  or  registration  of  a  supplier’s  quality  system. 


C5.2.3.5.4.  Acquisition  Logistics.  The  PM  shall  conduct  acquisition  logistics 
management  activities  throughout  the  program  life  cycle.  When  using  an  evolutionary 
acquisition  strategy,  acquisition  logistics  activities  shall  address  performance  and  support 
requirements  for  both  the  total  life  cycle  and  for  each  block,  and  shall  consider  and  mitigate  the 
impact  of  system  variants  or  variations.  The  supportability  of  the  design(s)  and  the  acquisition  of 
systems  shall  be  cost-effective  and  shall  provide  the  necessary  infrastructure  support  to  achieve 
peacetime  and  wartime  readiness  requirements.  Supportability  considerations  shall  be  integral  to 
all  trade-off  decisions. 


C5.2. 3.5.4. 1.  Supportability  Analyses.  PMs  shall  conduct  supportability 
analyses  as  an  integral  part  of  the  systems  engineering  process,  beginning  at  program  initiation 
and  continuing  throughout  the  program  life  cycle.  The  results  of  these  analyses  shall  form  the 
basis  for  the  related  design  requirements  included  in  the  system  performance  specification  and  in 
the  documentation  of  logistics  support  planning.  The  results  shall  also  support  subsequent 
decisions  to  achieve  cost-effective  support  throughout  the  system  life  cycle.  For  products,  this 
includes  all  new  procurements  and  major  modifications  and  upgrades,  as  well  as  reprocurement 
of  systems,  subsystems,  components,  spares,  and  services  that  are  procured  beyond  the  initial 
production  contract  award.  PMs  shall  permit  broad  flexibility  in  contractor  proposals  to  achieve 
program  supportability  objectives. 
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C5.2.3. 5.4.2.  Support  Concepts.  The  PM  shall  establish  logistics  support 
concepts  (e.g.,  organic,  two-level,  three-level,  contractor,  partnering,  etc.)  early  in  the  program 
and  refine  the  concepts  throughout  program  development.  TOC  shall  play  a  key  role  in  the 
overall  selection  process.  Support  concepts  for  all  systems  shall  provide  cost  effective,  total-life- 
cycle,  logistics  support. 

C5.2.3.5.4.3.  Support  Data.  Contract  requirements  for  deliverable  support  and 
support-related  data  shall  be  consistent  with  the  planned  support  concept,  and  shall  represent  the 
miniTmim  essential  requirements  to  cost-effectively  maintain  the  fielded  system  and  foster  source 
of  support  competition  throughout  the  life  of  the  fielded  system.  The  PM  shall  coordinate 
government  requirements  for  this  data  across  program  functional  specialties  to  minimize 
redundant  contract  deliverables  and  inconsistencies. 

C5.2.3. 5.4.4.  Support  Resources 

C5.2.3.5.4.4.1.  Support  resources,  for  both  the  total  system  over  the 
expected  life,  and  for  each  increment  of  introduced  capability,  are  inherent  to  “full  funding” 
calculations.  Therefore,  support  resources  requirements  shall  be  a  key  element  of  program 
reviews  and  decision  meetings.  During  program  planning  and  execution  logistics  support, 
products  and  services  shall  be  competitively  sourced.  The  PM  shall  consider  embedded  training 
and  maintenance  techniques  to  enhance  user  capability  and  reduce  life-cycle  costs. 

C5.2.3.5.4.4.2.  The  PM  shall  use  DoD  automatic  test  system  (ATS) 
families  or  COTS  components  that  meet  defined  ATS  capabilities  to  meet  all  acquisition  needs 
for  automatic  test  equipment  hardware  and  software.  Critical  hardware  and  software  elements 
shall  define  ATS  capabilities.  The  PM  shall  consider  diagnostic,  prognostic,  system  health 
management,  and  automatic  identification  technologies.  The  PM  shall  base  ATS  selection  on  a 
cost  and  benefit  analysis  over  the  complete  system  life  cycle.  Consistent  with  the  above  policy, 
the  PM  shall  minimize  the  introduction  of  unique  types  of  ATS  into  the  DoD  field,  depot,  and 
manufacturing  operations. 

C5.2.3.5.5.  Open  Systems  Design 

C5.2.3.5.5.1.  PMs  shall  use  a  modular,  standards-based  architecture  in  the 
design  of  systems.  They  shall  identify  key  interfaces  and  define  the  system  level  (system-of- 
systems,  system,  subsystem,  or  component)  at  and  above  which  these  interfaces  use  various 
types  of  standards.  Preference  shall  be  given  to  the  use  of  open  interface  standards  first,  then  to 
de  facto  interface  standards,  and  finally  to  government  and  proprietary  interface  standards.  PMs 
shall  report  on  their  progress  using  open  standards  for  key  interfaces  at  both  Milestones  B  and  C. 

C5.2.3.5.5.2.  PMs  shall  use  an  open  systems  approach  to  achieve  the 
following  objectives: 
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C5.2.3.5.5.2.1.  To  adapt  to  evolving  requirements  and  threats; 

C5.2.3.5.5.2.2.  To  accelerate  transition  from  science  and  technology  into 
acquisition  and  deployment; 


and  products; 
cost; 


C5.2.3.5.5.2.3.  To  enhance  modularity  and  facilitate  systems  integration; 
C5.2.3.5.5.2.4.  To  leverage  commercial  investment  in  new  technologies 

C5.2.3.5.5.2.5.  To  reduce  the  development  cycle  time  and  total  life-cycle 


C5.2.3.5 .5.2.6.  To  ensure  the  system  is  fully  interoperable  with  all 
systems  with  which  it  must  interface,  without  major  modification  of  existing  components; 


C5.2.3.5.5.2.7.  To  achieve  commonality  and  reuse  of  components  among 


systems; 


C5.2.3.5.5.2.8.  To  provide  users  the  ability  to  quickly  and  affordably 
interconnect  and  assemble  existing  platforms,  systems,  subsystems,  and  components  as  needed; 

C5.2.3.5.5.2.9.  To  maintain  continued  access  to  cutting  edge  technologies 
and  products  from  multiple  suppliers  during  initial  procurement,  reprocurement,  and  post- 
produetion  support; 


C5 .2.3.5.5.2.10.  To  mitigate  the  risks  associated  with  technology 
obsolescence,  being  locked  into  proprietary  technology,  and  reliance  on  a  single  source  of  supply 
over  the  life  of  a  system; 

C5.2.3.5.5.2. 11.  To  conduct  business  case  analyses  to  justify  decisions  to 
enhance  life-cycle  supportability  and  continuously  improve  product  affordability  through 
technology  insertion  during  initial  procurement,  reprocurement,  and  post-production  support; 
and 


C5.2.3.5.5.2.12.  To  facilitate  modular  contracting. 

C5.2.3.5.6.  Software  Management.  The  PM  shall  manage  and  engineer  software¬ 
intensive  systems  using  best  processes  and  practices  known  to  reduce  cost,  schedule,  and 
performance  risks. 

C5.2.3.5.6.1.  General.  The  PM  shall  base  software  systems  design  and 
development  on  systems  engineering  principles,  to  include  the  following: 
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C5.2.3.5.6.1.1.  Develop  architectural  based  software  systems  that  support 
open  system  concepts;  exploit  COTS  computer  systems  products;  and  allow  incremental 
improvements  based  on  modular,  reusable,  extensible  software; 

C5.2.3.5.6.1.2.  Identify  and  exploit,  where  practicable,  government  and 
commercial  software  reuse  opportunities  before  developing  new  software; 

C5.2.3.5.6.1.3.  Select  the  programming  language  in  context  of  the 
systems  and  software  engineering  factors  that  influence  overall  life-cycle  costs,  risks,  and  the 
potential  for  interoperability; 

C5.2.3.5.6.1.4.  Use  DoD  standard  data  and  follow  data  administrative 
policies  in  DoD  Directive  8320.1  (reference  (aaaa)); 

C5.2.3.5.6.1.5.  Select  contractors  with  domain  experience  in  developing 
comparable  software  systems;  with  successful  past  performance;  and  with  a  mature  software 
development  capability  and  process.  Contractors  performing  software  development  or 
upgrade(s)  for  use  in  an  AC  AT  I  or  ACAT  LA  program  shall  undergo  an  evaluation,  using  either 
the  tools  developed  by  the  Software  Engineering  Institute  (SEI),  or  those  approved  by  both  the 
DoD  Components  and  the  Deputy  Under  Secretary  of  Defense  (Science  and  Technology) 
(DUSD(S&T)).  At  a  minimum,  full  compliance  with  SEI  Capability  Maturity  Model  Level  3,  or 
its  equivalent  in  an  approved  evaluation  tool,  is  the  Department's  goal.  However,  if  the 
prospective  contractor  does  not  meet  fiill  compliance,  risk  mitigation  planning  shall  describe,  in 
detail,  the  schedule  and  actions  that  will  be  taken  to  remove  deficiencies  uncovered  in  the 
evaluation  process.  Risk  mitigation  planning  shall  require  PM  approval.  DUSD(S&T)  shall 
define  Level  3  equivalence  for  approved  evaluation  tools.  The  evaluation  shall  examine  the 
business  unit  proposed  to  perform  the  work.  The  reuse  of  existing  evaluation  results  performed 
within  a  two-year  period  prior  to  the  date  of  the  government  solicitation  is  encouraged. 

C5.2.3.5.6.L6.  Use  a  software  measurement  process  in  planning  and 
tracking  the  software  program,  and  to  assess  and  improve  the  software  development  process  and 
the  associated  software  product.  Provide  those  measures  to  the  appropriate  OSD  oversight 
office.  For  example,  MAIS  PMs  shall  follow  the  process  described  in  the  Practical  Software  and 
System  Measurement  Guidebook  (http://www.psmsc.com/). 

C5.2.3.5.6.1.7.  Assess  information  operations  risks  (DoD  Directive  S- 
3600.1  (reference  (bbbb)))  using  techniques  such  as  independent  expert  reviews; 

C5.2.3.5.6.L8.  Prepare  for  life-cycle  software  support  or  maintenance  by 
developing  or  acquiring  the  necessary  documentation,  host  systems,  test  beds,  and  computer- 
aided  software  engineering  tools  consistent  with  planned  support  concepts;  and  by  planning  for 
transition  of  fielded  software  to  the  support/maintenance  activity; 
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licenses;  and 


C5.2.3.5.6.1.9.  Track  COTS  software  purchases  and  maintenance 


C5.2.3.5.6.1.10.  Structure  a  software  development  process  that  recognizes 
that  emerging  requirements  will  require  modification  to  software  over  the  life  cycle  of  the 
system.  In  order  to  deliver  truly  state-of-the-sofiware,  this  process  should  allow  for  periodic 
software  enhancements. 

C5.2.3.5.6.2.  Software  Spiral  Development.  When  acquiring  software  for  a 
system,  the  PM  shall  plan  a  spiral  development  process  for  both  evolutionary  and  single-step-to- 
full-capability  acquisition  strategies.  A  cyclical,  iterative  build-test-fix-test-deploy  process 
characterizes  spiral  development  and  yields  continuous  improvements  in  software.  Each 
software  release  draws  upon  the  experience  and  lessons  of  previous  releases.  The  spiral 
development  process  shall  accomplish  the  following: 

C5.2.3.5.6.2.1.  Facilitate  requirements  changes  resulting  from  operational 
mission  needs,  technology  opportunities,  experimentation  results,  and  technology  obsolescence. 

C5.2.3.5.6.2.2.  Incorporate  T&E  of  operational  effectiveness,  suitability, 
and  supportability  using  experimentation,  demonstration,  rigorous  testing,  or  certification. 

C5.2.3.5.6.2.2.1.  The  T&E  process  shall  be  continuous  throughout 
the  system  life  cycle  and  involve  the  user,  contractor,  program  office,  and  test  community. 

C5.2.3.5.6.2.2.2.  The  T&E  process  shall  consider  the  near  continuous 
nature  of  change  in  the  baseline  and  use  techniques  such  as  regression  testing  to  ensure  that 
existing  functionality  has  not  been  compromised. 

C5.2.3.5.6.2.2.3.  The  PM  shall  consider  the  risks  and  extent  of 
change  impacts  to  enable  a  cost-effective,  yet  rigorous  T&E  process. 

C5.2.3.5.6.2.3.  Implement  configuration,  change,  and  data  management. 

C5.2.3.5.6.2.3.1.  Documented  actual  deployed  capability  provides  the 
starting  point  for  development  of  the  next  improvement  release  and  provides  a  baseline  for 
verification,  training,  etc. 


C5.2.3.5.6.2.3.2.  The  PM  shall  implement  a  configuration  control 
board  to  include  the  user,  program  office,  development  contractor,  integration  contractor  or 
agency,  and  any  other  critical  stakeholder. 

C5.2.3.5.6.2.3.3.  For  legacy  systems,  the  configuration  control  board 
shall  include  the  appropriate  support  and  sustainment  organizations. 
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C5.2.3.5.6.3.  Review  of  Software-Intensive  Programs.  An  independent  expert 
review  team  shall  review  programs  and  report  on  technology  and  development  risk,  cost, 
schedule,  design,  development,  project  management  processes  and  the  application  of  systems 
and  software  engineering  best  practices.  The  team  shall  report  their  findings  directly  to  the  PM 
and  the  PEO  or  equivalent  management  official.  DUSD(S&T)  shall  manage  the  team,  composed 
of  a  small  group  of  software  systems  engineering  and  technology  experts. 

C5.2.3.5.6.4.  Software  Security  Considerations.  The  following  security 
considerations  apply  to  software  management: 

C5.2.3.5.6.4.1.  A  documented  impact  analysis  statement,  which  addresses 
software  reliability,  shall  accompany  modifications  to  existing  DoD  software. 

C5.2.3.5.6.4.2.  The  PM  shall  establish  formal  software  change  control 

processes. 


C5.2.3.5.6.4.2.1.  Software  quality  assurance  personnel  shall  monitor 
the  software  change  process. 

C5.2.3.5.6.4.2.2.  An  independent  verification  and  validation  team 
shall  provide  additional  review. 

C5.2.3.5.6.4.3.  The  change  control  process  shall  indicate  whether  foreign 
nationals,  in  any  way,  participated  in  software  development,  modification,  or  remediation. 

C5.2.3.5.6.4.4.  Foreign  nationals  employed  by  contractors/subcontractors 
to  develop,  modify,  or  remediate  software  code  specifically  for  DoD  use  shall  each  have  a 
security  clearance  commensurate  with  the  level  of  the  program  in  which  the  software  is  being 
used. 


C5.2.3.5.6.4.5.  Primary  vendors  on  DoD  contracts  may  have 
subcontractors  who  employ  cleared  foreign  nationals  that  work  only  in  a  certified  or  accredited 
environment  (DoD  Instruction  5200.40  (reference  (iii))). 

C5.2.3.5.6.4.6.  Software  quality  assurance  persoimel  shall  review  DoD 
software  with  coding  done  in  foreign  environments  or  by  foreign  nationals  for  malicious  code. 

C5.2.3.5.6.4.7.  When  employing  COTS  software,  the  contracting  process 
shall  give  preference  during  product  selection/e  valuation  to  those  vendors  who  can  demonstrate 
that  they  took  efforts  to  minimize  the  security  risks  associated  with  foreign  nationals  that  have 
developed,  modified,  or  remediated  the  COTS  software  being  offered. 
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C5.2.3.5.6.4.8.  Software  quality  assurance  personnel  shall  check  software 
sent  to  locations  not  directly  controlled  by  the  Department  of  Defense  or  its  contractors  for 
malicious  code  when  returned  to  the  DoD  contractor’s  facilities. 

C5.2.3.5.7.  Commercial,  Off-the-Shelf  (COTS)  Considerations 

C5.2.3.5.7.1.  When  acquiring  COTS  software  products  or  other  commercial 
items,  the  PM  shall  implement  a  spiral  development  process  (see  subparagraph  C5.2.3. 5.6.2.).  In 
this  context,  integration  may  encompass  the  amalgamation  of  multiple  COTS  components  into 
one  deployable  system  (or  block  of  a  system)  or  the  assimilation  of  a  single  COTS  product  (such 
as  an  enterprise  resource  planning  system).  In  either  case,  the  PM  shall  ensure  that  the  system 
co-evolves  with  essential  changes  to  doctrine  (for  combat  systems)  or  reengineered  business 
processes  (for  combat  support  and  IT  systems).  The  PM  shall  apply  commercial  item  best 
practices. 


C5.2.3.5.7.2.  No  matter  how  much  of  a  system  is  provided  by  commercial 
items,  the  PM  shall  engineer,  develop,  integrate,  test,  evaluate,  deliver,  sustain,  and  manage  the 
overall  system.  Using  commercial  items  offers  significant  opportunities  for  reduced  cycle  time, 
faster  insertion  of  new  technology,  lower  life  cycle  costs,  greater  reliability  and  availability,  and 
support  from  a  more  robust  industrial  base.  The  keys  to  success  involve  thinking  and  acting  as 
an  informed  consumer;  planning  for  continuous  evolution  of  the  system;  and  maintaining  a 
flexible  posture  throughout  the  life  of  the  program.  The  use  of  commercial  items  often  requires 
changes  in  the  way  systems  are  conceived,  acquired,  and  sustained,  to  include: 

C5.2.3.5.7.2.1.  When  purchasing  a  commercial  item,  the  PM  shall  adopt 
commercial  business  practice(s).  The  extent  to  which  the  DoD  business  practices  match  the 
business  practices  supported  by  commercial  items  determines  the  likelihood  that  the  items  will 
meet  DoD  needs.  It  is  likely,  however,  that  a  gap  will  exist — and  the  gap  may  be  large. 
Negotiation,  flexibility,  and  communication  on  the  part  of  the  stakeholders,  the  commercial 
vendors,  and  the  program  manager  are  required. 

C5.2.3.5.7.2.2.  The  PM  shall  plan  for  robust  evaluations  to  assist  in  fully 
identifying  commercial  capabilities,  to  choose  between  alternate  architectures  and  designs,  to 
determine  whether  new  releases  continue  to  meet  requirements,  and  to  ensure  that  the 
commercial  items  function  as  expected  when  linked  to  other  system  components.  In  addition, 
evaluation  provides  the  critical  source  of  information  about  the  trade-offs  that  must  be  made 
between  the  capabilities  of  the  system  to  be  fielded  and  the  system  architecture  and  design  that 
makes  best  use  of  commercial  capabilities.  Evaluating  commercial  items  requires  a  focus  on 
mission  accomplishment,  and  matching  the  commercial  item  to  system  requirements. 

C5.2.3.5.7.2.3.  The  PM  shall  remain  aware  of  and  influence  product 
enhancements  with  key  commercial  item  vendors  to  the  extent  practical  and  in  compliance  with 
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FACA  (reference  (cc)).  Vendors  are  different  from  contractors  and  subcontractors;  different 
practices  and  relationships  are  needed.  Vendors  react  to  the  marketplace,  not  the  unique  needs  of 
DoD  programs.  To  successfully  work  with  vendors,  the  PM  shall  adopt  practices  and 
expectations  that  are  similar  to  other  buyers  in  the  marke^lace.  Traditional  DoD  acquisition  and 
business  models  are  not  sufficient  for  programs  acquiring  commercial  items,  as  they  do  not  take 
into  account  the  marketplace  factors  that  motivate  vendors. 

C5.2.3.5.7.2.4.  The  PM  shall  engineer  the  system  architecture  and 
establish  a  rigorous  change  management  process  for  life-cycle  support.  Systems  that  integrate 
multiple  commercial  items  require  extensive  engineering  to  facilitate  the  insertion  of  plaimed 
new  commercial  technology.  This  is  not  a  “one  time”  activity  because  unanticipated  changes 
may  drive  reconsideration  of  engineering  decisions  throughout  the  life  of  the  program.  Failure  to 
address  changes  in  commercial  items  and  the  marketplace  will  potentially  result  in  a  system  that 
cannot  be  maintained  as  vendors  drop  support  for  obsolete  commercial  items. 

C5.2.3.5.7.2.5.  The  PM  shall  develop  an  appropriate  T&E  strategy  for 
commercial  items  to  include  evaluating  potential  commercial  items  in  a  system  test  bed,  when 
practical;  focusing  test  beds  on  high-risk  items;  and  testing  commercial-item  upgrades  for 
unanticipated  side  effects  in  areas  such  as  security,  safety,  reliability,  and  performance. 

C5.2.3.5.7.2.6.  Programs  are  encouraged  to  use  code-scanning  tools, 
within  the  scope  and  limitations  of  the  licensing  agreements,  to  ensure  both  COTS  and 
Government  off-the-shelf  software  do  not  pose  any  information  assurance  or  security  risks. 

C5.2.3.5.8.  Reliability,  Availability,  and  Maintainability  (RAM) 

C5.2.3.5.8.1.  The  PM  shall  establish  RAM  activities  early  in  the  acquisition 
cycle.  The  PM  shall  develop  RAM  system  requirements  based  on  the  ORD  and  TOC 
considerations,  and  state  them  in  quantifiable,  operational  terms,  measurable  during  DT&E  and 
OT&E.  RAM  system  requirements  shall  address  all  elements  of  the  system,  including  support 
and  training  equipment.  They  shall  be  derived  from,  and  support,  the  user's  system  readiness 
objectives.  Reliability  requirements  shall  address  mission  reliability  and  logistic  reliability. 
Availability  requirements  shall  address  the  readiness  of  the  system.  Maintainability 
requirements  shall  address  servicing,  preventive,  and  corrective  maintenance. 

C5.2.3.5.8.2.  The  PM  shall  plan  and  execute  RAM  design,  manufacturing 
development,  and  test  activities  so  that  the  system  elements,  including  software,  used  to 
demonstrate  system  performance  before  the  production  decision  reflect  the  mature  design. 
lOT&E  shall  use  production  representative  systems,  actual  operational  procedures,  and  personnel 
with  representative  skill  levels.  To  reduce  testing  costs,  the  PM  shall  utilize  M&S  in  the 
demonstration  of  RAM  requirements  wherever  appropriate. 
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C5.2.3.5.8.3.  This  policy  applies  not  only  to  the  system,  but  also  to  techmcal 
manuals,  spare  parts,  tools,  and  support  equipment. 

C5.2.3.5.9.  HSI.  For  all  programs  regardless  of  ACAT,  the  PM  shall  initiate  a 
comprehensive  strategy  for  HSI  early  in  the  acquisition  process  to  minimize  ownership  costs  and 
ensure  that  the  system  is  built  to  accommodate  the  human  performance  characteristics  of  the  user 
population  that  will  operate,  maintain,  and  support  the  system.  The  PM  shall  work  with  the 
manpower,  personnel,  training,  safety  and  occupational  health  (see  paragraph  C5.2.3.5.10.), 
habitability,  survivability,  and  HFE  communities  to  translate  the  HSI  thresholds  and  objectives  in 
the  ORD  into  quantifiable  and  measurable  system  requirements.  The  PM  shall  include  these 
requirements  in  specifications,  the  TEMP,  and  other  program  documentation,  as  appropriate,  and 
use  them  to  address  HSI  in  the  statement  of  work  and  contract.  The  PM  shall  identify  any  HSI- 
related  schedule  or  cost  issues  that  could  adversely  impact  program  execution. 

C5.2.3.5.9.1.  HFE.  The  PM  shall  employ  HFE  during  systems  engineering  (to 
include  function  allocation)  to  provide  for  effective  human-machine  interfaces.  Where 
practicable  and  cost  effective,  design  efforts  shall  seek  to  reduce  manpower  and  training 
requirements.  Design  efforts  shall  minimize  or  eliminate  system  characteristics  that  require 
excessive  cognitive,  physical,  or  sensory  skills;  require  extensive  training  or  workload-intensive 
tasks;  result  in  mission-critical  errors;  or  produce  safety  or  health  hazards. 

C5.2.3. 5.9.2.  Habitability  and  Personnel  Survivability.  The  PM  shall  work 
with  habitability  and  survivability  representatives  (see  subparagraphs  C2.8.5.4.  and  C5 .2.3.5. 12.) 
to  set  requirements  for  the  physical  environment  and,  if  appropriate,  essential  personnel  services 
(e.g.,  medical  and  mess)  and  minimum  living  conditions  (e.g.,  berthing  and  personal  hygiene) 
that  have  a  direct  impact  on  sustained  mission  effectiveness  and  recruitment  and  retention. 

C5.2.3.5.9.3.  Manpower  Initiatives.  The  PM  shall  work  with  manpower  and 
functional  representatives  to  identify  workload  intensive  tasks,  process  improvements,  design 
options,  or  other  initiatives  to  reduce  manpower,  improve  the  efficiency  or  effectiveness  of 
support  services,  or  enhance  the  cross-functional  integration  of  support  activities. 

C5.2.3.5.9.4.  Personnel  Initiatives.  The  PM  shall  work  with  the  personnel 
community  and  consider  current  personnel  policy  and  recruitment  trends  when  defining  the 
human  performance  characteristics  of  the  user  population.  To  the  extent  possible,  systems  shall 
not  require  special  cognitive,  physical,  or  sensory  skills  beyond  that  found  in  the  specified  user 
population. 


C5.2.3.5.9.5.  Training.  As  platform  functions  become  increasingly  automated, 
HSI  shall  match  the  cognitive  processes  of  the  operators  and  maintainers  to  the  information 
processes  of  the  platform.  Training  subsystems,  including  training  aids,  devices,  simulations, 
and  simulators  (commonly  known  as  “TADSS”)  and  embedded  training  capability  (where 
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appropriate),  shall  evolve  from  being  separate  support  functions  into  being  an  integral  part  of  the 
platform’s  information  architecture.  The  PM  shall  consider  design  options  and  emerging 
training  technologies  that  can  improve  the  users'  performance  and  readiness,  and  reduce 
individual,  collective,  and  joint  training  costs.  The  PM  shall  maximize  simulation-supported 
embedded  training.  Training  systems  shall  fully  support  and  mirror  the  interoperability  of  the 
operational  system.  The  PM  shall  base  training  decisions  on  training  effectiveness  evaluations 
(see  DoD  Directive  1430.13  (reference  (v))).  The  PM  shall  document  manpower  and  training 
requirements  as  soon  as  possible  after  program  initiation. 

C5.2.3.5.10.  Environment,  Safety,  and  Occupational  Health  (ESOH) 

C5.2. 3.5. 10.1.  All  programs,  regardless  of  acquisition  category  and  throughout 
their  life  cycle,  shall  comply  with  this  section.  The  PM  shall  ensure  a  system  design  that  can  be 
tested,  operated,  maintained,  repaired,  and  disposed  of  in  accordance  with  ESOH  statutes, 
regulations,  policies,  and,  as  applicable,  environmental  treaties  and  agreements  (collectively 
termed  regulatory  requirements)  and  the  requirements  of  this  section. 

C5.2. 3.5. 10.2.  The  PM  shall  prepare  a  PESHE  document  early  in  the  program 
life  cycle  (usually  Milestone  B).  The  PESHE  shall  identify  ESOH  risks,  contain  a  strategy  for 
integrating  ESOH  considerations  into  the  systems  engineering  process,  delineate  ESOH 
responsibilities,  and  provide  a  method  for  tracking  progress.  The  PM  shall  use  the  PESHE  to 
identify  and  manage  ESOH  hazards,  and  to  determine  how  to  best  meet  ESOH  regulatory 
requirements.  The  PM  shall  keep  the  PESHE  updated  over  the  system  life  cycle. 

C5.2. 3.5. 10.3.  The  PM  shall  conduct  ESOH  analyses  as  described  below.  The 
PM  shall  provide  details  of  these  analyses,  including  supporting  documentation,  as  part  of  the 
IPPD. 


C5.2. 3.5. 10.4.  ESOH  Compliance.  To  minimize  the  cost  and  schedule  risks 
over  the  system's  life  cycle  that  changing  ESOH  requirements  and  regulations  represent,  the  PM 
shall  regularly  review  ESOH  regulatory  requirements  and  evaluate  their  impact  on  the  program’s 
life-cycle  cost,  schedule,  and  performance. 

C5.2.3.5.10.5.  National  Environmental  Policy  Act  (NEP A).  The  PM  is 
responsible  for  and  shall  comply  with  the  NEPA  (42  U.S.C.  4321-4370d  (reference  (fff)))  and 
implementing  regulations,  40  C.F.R.  1500-1508  (reference  (cccc)),  and  E.O.  12114  (reference 
(ggg)),  as  applicable.  The  PM  shall  complete  any  analysis  and  documentation  required  under 
either  NEPA  or  E.O.  12114  before  the  appropriate  official  may  make  a  decision  to  proceed  with 
a  proposed  action  that  may  affect  the  human  environment.  The  PM  shall  document  the  decision 
before  implementing  the  proposed  action.  The  PM  shall  include  an  appropriate  completion 
schedule  for  NEPA  and  E.O.  121 14  compliance  in  the  acquisition  strategy.  The  PM  shall 
prepare  NEPA  and  E.O.  12114  documentation  in  accordance  with  the  DoD  Component 
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implementation  regulations  and  guidance.  The  CAE  (or,  for  joint  programs,  the  CAE  of  the 
Lead  Executive  Component),  or  designee,  is  the  final  approval  authority  for  system-related 
NEPA  and  E.O.  121 14  documentation.  The  PM  shall  forward  a  copy  of  final  NEPA 
documentation  to  the  Defense  Technical  Information  Center  for  archiving. 


C5.2. 3.5. 10.6.  Safety  and  Health 

C5.2.3.5. 10.6.1.  The  PM  shall  identify  and  evaluate  safety  and  health 
hazards,  define  risk  levels,  and  establish  a  program  that  manages  the  probability  and  severity  of 
all  hazards  associated  with  development,  use,  and  disposal  of  the  system.  The  PM  shall  use  and 
require  contractors  to  use  the  industry  and  DoD  standard  practice  for  system  safety,  consistent 
with  mission  requirements.  This  standard  practice  manages  risks  encountered  in  the  acquisition 
life  cycle  of  systems,  subsystems,  equipment,  and  facilities.  These  risks  include  conditions  that 
create  significant  risks  of  death,  injury,  acute/chronic  illness,  disability,  and/or  reduced  job 
performance  of  personnel  who  produce,  test,  operate,  maintain,  support,  or  dispose  of  the  system. 

C5.2. 3.5. 10.6.2.  The  following  policy  applies  to  the  acceptance  of  risk: 

C5.2.3. 5. 10.6.2.1.  The  PM  shall  formally  document  each 
management  decision  accepting  the  risk  associated  with  an  identified  hazard. 

C5.2.3.5. 10.6.2.2.  “High  Risk”  hazards  shall  require  CAE  approval 
(Lead  Executive  Component  authority  prevails  for  joint  programs). 

C5.2.3.5.10.6.2.3.  The  acceptance  of  all  risks  involving  explosives 
safety  (see  subparagraph  C5 .2.3.5. 10.9.)  shall  require  the  appropriate  risk  acceptance  authority  to 
consult  with  the  DoD  Component’s  technical  authority  managing  the  explosives  safety  program. 


approval. 


C5.2.3.5.10.6.2.4.  “Serious  Risk”  hazards  shall  require  PEG 


require  PM  approval. 


C5.2.3.5.10.6.2.5.  “Medium  Risk”  and  "Low  Risk"  hazards  shall 


C5.2. 3.5. 10.6.3.  Pub.  L.  91-596  (1990)  (reference  (dddd))  makes  Federal 
Occupational  Safety  and  Health  Act  standards  and  regulations  applicable  to  all  federal  (military 
or  civilian)  and  contractor  employees  working  on  DoD  acquisition  contracts  or  in  DoD 
operations  and  workplaces.  In  the  case  of  military-unique  equipment,  systems,  operations,  or 
workplaces.  Federal  safety  and  health  standards,  in  whole  or  in  part,  shall  apply  to  the  extent 
practicable. 
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C5.2.3.5.10.7.  Hazardous  Materials  Management 

C5.2.3.5. 10.7.1.  The  PM  shall  establish  a  hazardous  material  management 
program  consistent  with  eliminating  and  reducing  the  use  of  hazardous  materials  in  processes 
and  products  (E.O.  13148  (reference  (eeee))).  The  PM  shall  evaluate  and  manage  the  selection, 
use,  and  disposal  of  hazardous  materials  consistent  with  ESOH  regulatory  requirements  and 
program  cost,  schedule,  and  performance  goals.  Where  the  PM  cannot  avoid  using  a  hazardous 
material,  he  or  she  shall  develop  and  implement  plans  and  procedures  for  identifying, 
minimizing  use  of,  tracking,  storing,  handling,  packaging,  transporting,  and  disposing  of  such 
material. 


C5.2.3.5. 10.7.2.  As  alternate  technology  becomes  available,  the  PM  shall 
replace  hazardous  materials  in  the  system  through  changes  in  llie  system  design,  manufacturing, 
and  maintenance  processes,  where  technically  and  economically  practicable.  To  mimmize  costs, 
the  PM  shall,  whenever  possible,  work  with  the  contractor  and  other  PMs  to  identify  and  test 
mutually  acceptable  alternatives.  DCMA  shall  coordinate  this  effort  at  contractor  facilities  under 
its  cognizance.  Where  the  Supervisor  of  Shipbuilding,  Conversion,  and  Repair  (SUPSHIP) 
provides  contract  management,  the  PM  shall  coordinate  with  SUPSHIP .  The  Contract 
Management  Office,  working  in  conjunction  with  the  PM  and  IPT,  shall  help  identify  technical 
requirements,  coordinate  PM  funding  strategies,  administer  evaluation  activities,  and  implement 
solutions. 


C5.2.3.5.10.8.  Pollution  Prevention 

C5.2.3.5. 10.8.1.  The  PM  shall  identify  and  evaluate  environmental  and 
occupational  health  hazards  and  establish  a  pollution  prevention  program.  The  PM  shall  identify 
the  impacts  of  the  system  on  the  environment  during  its  life  (including  disposal),  the  types  and 
amoimts  of  pollution  from  all  sources  (air,  water,  noise,  etc.)  that  will  be  released  to  the 
environment,  actions  needed  to  prevent  or  control  the  impacts,  ESOH  risks  associated  with  using 
the  new  system,  and  other  information  needed  to  identify  source  reduction,  alternative 
technologies,  and  recycling  opportunities.  The  pollution  prevention  program  shall  serve  to 
minimize  system  impacts  on  the  environment  and  human  health,  as  well  as  environmental 
compliance  impacts  on  program  TOC.  A  fundamental  purpose  of  the  pollution  prevention 
program  is  to  identify  and  quantify  impacts,  such  as  noise,  as  early  as  possible  during  system 
development,  and  to  identify  and  implement  actions  needed  to  prevent  or  abate  the  impacts. 

C5.2. 3.5. 10.8.2.  In  developing  contract  documents  such  as  work 
statements,  specifications,  and  other  product  descriptions,  PMs  shall  eliminate  the  use  of  virgin 
material  requirements,  as  practicable.  They  shall  consider  using  recovered  materials  and 
reusable  products.  They  shall  further  consider  life-cycle  costs,  recyclability,  the  use  of 
environmentally  preferable  products,  waste  prevention  (including  toxicity  reduction  or 
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elimination),  and  disposal,  as  appropriate.  (FAR  11.002  and  E.0. 13101  (references  (ffff)  and 
(gggg))) 


C5.2.3.5.10.9.  Explosives  Safety.  All  acquisition  programs  that  mclude  or 
support  munitions,  explosives,  or  energetics  shall  comply  with  DoD  explosives  safety 
requirements.  The  PM  shall  establish  an  explosives  safety  program  that  ensures  that  munitions, 
explosives,  and  energetics  are  properly  hazard  classified,  and  safely  developed,  manufactured, 
tested,  transported,  handled,  stored,  maintained,  demilitarized,  and  disposed.  The  PM  shall 
evaluate  and  manage  the  use  and  selection  of  energetic  materials  and  the  design  of  munitions  and 
explosive  systems  to  reduce  the  possibility  and  the  consequences  of  any  munitions  or  explosives 
mishap  and  to  optimize  the  trade-off  of  munitions  reliability  against  imexploded  ordnance 
liability. 


C5.2.3.5.1 1.  Interoperability.  All  acquisition  programs  shall  satisfactorily  address 
interoperability  and  integration.  Users  shall  specify,  and  the  appropriate  authority  shall  validate, 
thresholds  and  objectives  during  the  requirements  generation  process.  The  Joint  Staff  shall 
certify  interoperability  requirements.  These  requirements  shall  span  the  complete  acquisition  life 
cycle  for  all  acquisition  programs.  Interoperability  and  supportability  of  IT  acquisition  program 
systems,  including  NSS,  shall  comply  with  DoD  Directive  4630.5  (reference  (hhhh)),  DoD 
Instruction  4630.8  (reference  (iiii)),  and  CJCS  Instruction  6212.01B  (reference  (jjjj)).  (Pub.  L. 
104-106  (1996)  (reference  (kkkk))  and  44  U.S.C.  3506  (reference  (c))) 

C5. 2.3. 5.1 1.1.  IT  Design  Considerations.  Available  mission  area  (i.e.,  joint 
mission  area  and/or  business/administrative  mission  areas)  integrated  architectures  shall  be  used 
to  develop  IT,  including  NSS,  interoperability  requirements.  The  Joint  Operational  Architecture 
and  the  JTA  shall  serve  as  the  foundation  for  evolutionary  development  of  these  mission  area 
integrated  architectures.  Mission  area  integrated  architectures  shall  state  IT,  including  NSS, 
interoperability  requirements  in  a  family-of-systems  mission  area  context.  The  user  shall  derive 
IT,  including  NSS,  family-of-systems  ii^ormation  exchange  requirements  (lERs)  fi'om  the 
operational  lERs  of  the  mission  area  integrated  architecture.  During  the  requirements  generation 
process,  users  shall  develop  interoperability  KPPs  in  accordance  with  DoD  Directive  4630.5 
(reference  (hhhh)),  DoD  Instruction  4630.8  (reference  (iiii)),  CJCS  Instruction  3170.01B 
(reference  (f)),  and  CJCS  Instruction  6212.01B  (reference  (jjjj))  for  all  CRDs  and  ORDs.  The 
DoD  Components  shall  incorporate  the  lERs  into  the  C4ISP  (see  Appendix  5). 

C5.2.3.5.11.2.  DoD  Joint  Technical  Architecture  (JTA).  Implementation  of 
the  JTA  is  the  use  of  applicable  standards  cited  as  mandated  in  the  JTA.  The  implementation  of 
the  JTA  is  required  for  all  new,  or  changes  to  existing,  IT,  including  NSS.  If  the  use  of  a  JTA- 
mandated  standard  will  negatively  impact  cost,  schedule,  or  performance,  a  DoD  CAE  or 
cognizant  OSD  PSA  may  grant  a  waiver  firom  use.  For  mission  critical  or  mission  essential 
programs,  all  granted  waivers  shall  be  submitted  through  ASD(C3I)/DoD  CIO  to  USD(AT&L) 
for  review.  If  no  response  is  received  within  2  weeks  of  the  date  of  receipt,  concurrence  can  be 
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assumed.  To  assure  proper  and  timely  consideration,  all  requests  for  a  waiver  shall  state  the  cost, 
schedule,  and  performance  impacts  that  will  occur  if  the  waiver  is  not  granted,  and  any  resulting 
operational  limitations. 

C5.2.3.5.1 1.3.  Other  than  IT  Design  Considerations.  Consistent  with  the 
interoperability  KPP,  the  proposed  system  shall  functionally  operate  with  other  systems,  umts,  or 
forces,  to  include  U.S.  and  U.S.  coalition  partners;  allow  appropriate  training  with  other  systems, 
units,  or  forces;  physically  integrate  with  other  systems,  units,  or  forces  (considering  chemical, 
mechanical,  electrical,  etc.  interfaces);  provide  services  to  and  accept  services  from  other 
systems,  units,  or  forces;  and  use  the  exchanged  services  and  physical  integration  to  operate 
effectively  together. 

C5 .2.3.5. 1 1.4.  Standardization  Considerations.  Standardization  advances 
interoperability  through  commonality  of  systems,  subsystems,  components,  equipment,  data,  and 
architectures.  The  PM  shall  balance  decisions  to  use  standard  systems,  subsystems,  and  support 
equipment,  against  specific  mission  requirements  (including  corresponding  information  system 
elements  that  perform  critical  essential,  or  support  functions  with  each  mission  area),  technology 
growth,  and  cost  effectiveness.  The  PM  shall  comply  with  the  policy  on  military  specifications 
and  standards  in  paragraph  C5.3.2.  PMs  shall  consider  compliance  with  international 
standardization  agreements,  such  as  the  NATO  Standardization  Agreements,  or  the  agreements 
of  the  Air  Standards  Coordinating  Committee  or  American-British-Canadian- Australian  Armies. 
The  PM  shall  identify  any  international  standardization  agreements  or  U.S.  implementing 
documents  that  apply  to  the  program  early  in  the  design  process  to  ensure  interoperability  with 
allied  systems  and  equipment.  The  PM  shall  employ  systems  engineering  analysis  if  compliance 
with  the  JTA  or  other  international  standardization  agreements  and/or  other  standards  does  not 
provide  sufficient  interoperability  to  satisfy  user  requirements. 

C5 .2.3.5. 12.  Survivability.  Unless  waived  by  the  MDA,  mission-critical  systems, 
including  crew,  regardless  of  ACAT,  shall  be  survivable  to  the  threat  levels  anticipated  in  their 
projected  operating  environment  as  portrayed  in  the  System  Threat  Assessment.  Design  and 
testing  shall  ensure  that  the  system  and  crew  can  withstand  man-made  hostile  environments 
without  the  crew  suffering  acute  chronic  illness,  disability,  or  death. 

C5.2.3.5.12.1.  The  PM  shall  fully  assess  system  and  crew  survivability  against 
all  anticipated  threats  at  all  levels  of  conflict,  early  in  the  program,  but  in  no  case  later  than 
entering  system  demonstration  or  equivalent.  This  assessment  shall  also  consider  fratricide  and 
detection.  If  the  system  or  program  has  been  designated  by  DOT&E,  for  LFT&E  oversight  (see 
section  C3.8.),  the  PM  shall  integrate  the  T&E  used  to  address  crew  survivability  issues  into  the 
LFT&E  program  supporting  the  Secretary  of  Defense  LFT&E  Report  to  Congress  (see  paragraph 
C3.11.2.)  (10  U.S.C.  2366  (reference  (w))). 
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C5.2.3.5.12.2.  The  PM  shall  establish  and  maintain  a  survivability  program 
throughout  the  system  life  cycle  to  attain  overall  program  objectives.  The  program  shall  stress 
early  investment  in  survivability  enhancement  efforts  that  improve  system  operational  readiness 
and  mission  effectiveness  by: 

C5.2.3.5.12.2.1.  Providing  threat  avoidance  capabilities  (low 

susceptibility); 

C5.2.3.5. 12.2.2.  Incorporating  hardening  and  threat  tolerance  features  in 
system  design  (low  vulnerability); 

C5.2.3.5. 12.2.3.  Providing  design  features  to  reduce  personnel  casualties 
resulting  from  damage  to  or  loss  of  the  aircraft  (casualty  reduction); 

C5.2.3.5. 12.2.4.  Maximizing  wartime  availability  and  sortie  rates  via 
operationally  compatible  threat  damage  tolerance  and  rapid  reconstitution  (reparability)  features; 

C5.2.3.5. 12.2.5.  Minimizing  survivability  program  impact  on  overall 
program  cost  and  schedule;  and, 

C5.2.3.5. 12.2.6.  Ensuring  protection  coimtermeasures  and  systems 
security  applications  are  defined  for  critical  component's  vulnerability  to  validated  threats  for 
systems  survivability,  including  conventional  or  nuclear  advanced  technology  weapons;  nuclear, 
biological,  or  chemical  contamination;  and  EW  threats. 

C5.2.3.5. 13.  Mission  Assuredness.  The  PM  shall  consider  survivability  and 
mission  assuredness  of  systems  vulnerable  to  physical  and  electronic  attack.  Security, 
survivability,  and  operational  continuity  (i.e.,  protection)  shall  be  considered  as  techmcal 
performance  requirements  as  they  support  achievement  of  other  technical  performance  aspects 
such  as  accuracy,  endurance,  sustainability,  interoperability,  range,  etc.,  as  well  as  mission 
effectiveness  in  general  (see  section  C6.6.).  The  PM  shall  include  the  considerations  in  the  risk 
benefit  analysis  of  system  design  and  cost.  Users  shall  be  familiar  with  critical  infrastructure 
protection  and  space  control  requirements,  and  accoimt  for  necessary  hardening,  redimdancy, 
backup,  and  other  physical  protection  measures  in  developing  system  and  family-of-system 
requirements. 


C5.2.3.5.14.  Information  Assurance  Requirements.  The  PM  shall  incorporate 
information  assurance  requirements  into  program  design  activities  to  ensure  availability, 
integrity,  authentication,  confidentiality,  and  non-repudiation  of  critical  system  information.  The 
PM  shall  consider  the  restoration  of  information  systems  by  incorporating  protection,  detection, 
and  reaction  capabilities  during  system  design.  All  automated  information  systems  shall  meet 
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the  security  requirements  of  DoD  Directive  5200.28  (reference  (1111))  and  the  accreditation 
requirements  of  DoD  Instruction  5200.40  (reference  (iii)). 

C5.2.3.5.15.  Anti-Tamper  Provisions.  Anti-tamper  activities  encompass  the 
system  engineering  activities  intended  to  prevent  and/or  delay  exploitation  of  critical 
technologies  in  U.S.  systems.  These  activities  involve  the  entire  life  cycle  of  systems 
acquisition,  including  research,  design,  development,  testing,  implementation,  and  validation  of 
anti-tamper  measures.  Properly  employed,  anti-tamper  measures  will  add  longevity  to  a  critical 
technology  by  deterring  efforts  to  reverse-engineer,  exploit,  or  develop  countermeasures  against 
a  system  or  system  component. 

C5.2.3.5.15.1.  The  PM  shall  develop  and  implement  anti-tamper  measures  for 
all  programs  in  accordance  with  the  determination  of  the  MDA  as  documented  in  the  anti-tamper 
annex  to  the  program  protection  plan.  Anti-tamper  capability,  if  determined  to  be  required  for  a 
system,  must  be  reflected  in  the  systems  specifications,  integrated  logistics  support  plan,  and 
other  program  documents  and  design  activities.  Because  of  its  function,  anti-tamper  should  not 
be  regarded  as  an  option  or  a  system  capability  that  may  later  be  traded  off  without  a  thorough 
operational  and  acquisition  risk  analysis.  To  accomplish  this,  the  PM  shall  identify  critical 
technologies,  identify  system  vulnerabilities,  and,  with  assistance  from  counter-intelligence 
organizations,  perform  threat  analyses  to  the  critical  technologies.  The  PM  shall  research  anti¬ 
tamper  measures  and  determine  which  best  fit  the  performance,  cost,  schedule,  and  risk  of  the 
program. 


C5.2.3.5.15.2.  The  PM  shall  plan  for  post-production  anti-tamper  validation  of 
end  items.  The  Department’s  anti-tamper  executive  agent  shall  execute  the  validation  plan 
approved  by  the  MDA  and  report  results  to  the  SAE  and  USD(AT&L). 

C5.3.  OTHER  DESIGN  CONSIDERATIONS 

The  PM  shall  consider  the  following  topics  during  program  design  and  comply  with  each,  as 
appropriate. 

C5.3.1 .  Work  Breakdown  Structure  (WBS).  Systems  engineering  shall  yield  a  program 
WBS.  The  PM  shall  prepare  the  WBS  in  accordance  with  the  WBS  guidance  in  MIL-HDBK- 
881  (reference  (mmmm)).  The  WBS  provides  the  framework  for  program  and  technical 
planning,  cost  estimating,  resource  allocation,  performance  measurement,  technical  assessment, 
and  status  reporting.  The  WBS  shall  include  the  WBS  dictionary.  The  WBS  shall  define  the 
system  to  be  developed  or  produced.  It  shall  display  the  system  as  a  product-oriented  family  tree 
composed  of  hardware,  software,  services,  data,  and  facilities.  It  shall  relate  the  elements  of 
work  to  each  other  and  to  the  end  product.  The  PM  shall  normally  specify  contract  WBS 
elements  only  to  level  three  for  prime  contractors  and  key  subcontractors.  Only  low-level 
elements  that  address  high  risk,  high  value,  or  high  technical  interest  areas  of  a  program  shall 
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require  detailed  reporting  below  level  three.  The  PM  shall  have  only  one  WBS  for  each 
program. 

C5.3.2.  Performance  Specifications.  The  Department  shall  use  performance  specifications 
(i.e.,  DoD  performance  specifications,  commercial  item  descriptions,  and  performance-based 
non-government  standards)  when  purchasing  new  systems,  major  modifications,  upgrades  to 
current  systems,  and  commercial  and  non-developmental  items  for  programs  in  all  acquisition 
categories.  The  Department  shall  emphasize  conversion  to  performance  specifications  for 
reprocurements  of  existing  systems  at  the  subsystems  level;  and  for  components,  spares,  and 
services,  where  supported  by  a  business  case  analysis;  for  programs  in  all  acquisition  categories. 

C5.3.2.1.  Implementing  Performance  Specifications 

C5.3.2.1.1.  If  performance  specifications  are  not  practicable,  the  Department  shall 
use  non-Govemment  standards.  The  following  additional  policy  shall  apply: 

C5.3 .2. 1 . 1 . 1 .  If  no  acceptable  non-Govemmental  standards  exist,  or  if  using 
performance  specifications  or  non-Govemment  standards  is  not  cost  effective,  not  practical,  or 
does  not  meet  the  users’  needs,  over  a  product’s  life  cycle,  the  Department  may  define  an  exact 
design  solution  with  military  specifications  and  standards,  as  last  resort,  with  MDA-approved 
waiver. 


C5.3.2.1.1.2.  The  CAE,  or  designee,  may  grant  waivers  for  military 
specifications  or  standards  across  all  programs. 

C5.3.2.1.1.3.  Waiver  authorities  may  grant  waivers  for  military  specifications 
or  standards  for  all  or  for  a  portion  of  the  life  of  the  system. 

C5.3.2.1.1.4.  Military  specifications  and  standards  contained  in  contracts  and 
product  configuration  technical  data  packages  for  reprocurement  of  items  already  in  inventory 
shall  comply  with  the  following: 

C5.3 .2.1.1 .4. 1 .  Be  streamlined  to  remove  non-value-added  management, 
process,  and  oversight  specifications  and  standards. 

C5.3.2.1.1.4.2.  Be  replaced  by  Single  Process  Initiatives  to  improve 

product  affordability. 


C5.3.2.1. 1.4.3.  When  justified  as  economically  beneficial  over  the 
remaining  product  life  cycle  by  a  business  case  analysis,  convert  to  performance-based 
acquisition  and  form,  fit,  function,  and  interface  specifications  to  support  programs  in  on-going 
procurement,  future  reprocurement,  and  post-production  support. 
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C5. 3.2.1. 1.5.  The  Director,  Naval  Nuclear  Propulsion,  shall  determine 
specifications  and  standards  for  naval  nuclear  propulsion  plants,  in  accordance  with  42  U.S.C. 
7158  andE.O.  12344  (references  (nnnn)  and  (oooo)). 

C5.3.2.1.2.  DoD  Instruction  4120.24  and  DoD  4120.24-M  (references  (pppp)  and 
(qqqq))  contain  additional  standardization  guidance. 

C5.3.2.2.  Implementing  a  Performance-Based  Business  Environment  (PBBE) 
C5.3.2.2.1.  The  PM  shall  structure  the  PBBE  to  accomplish  the  following: 

C5.3 .2.2. 1.1.  Convey  product  definition  to  industry  in  performance  terms; 

C5.3.2.2.1.2.  Use  systems  engineering  and  management  practices,  including 
affordability,  IPPD,  and  support,  to  fully  integrate  total  life  cycle  considerations; 

C5.3.2.2.1.3.  Increase  emphasis  on  past  performance; 

C5.3.2.2.1.4.  Motivate  process  efficiency  and  effectiveness  up  and  down  the 
entire  supplier  base— primes,  subcontractors  and  vendors-through  the  use  of  contractor  chosen 
commercial  products,  practices,  and  processes; 

C5.3.2.2.1.5.  Encourage  life-cycle  risk  management  versus  risk  avoidance; 

C5.3.2.2.1.6.  Simplify  acquisition  and  support  operating  methods  by 
transferring  tasks  to  industry  where  cost  effective,  risk-acceptable,  commercial  capabilities  exist; 
and 


C5.3.2.2.1.7.  Use  performance  requirements  or  conversion  to  performance 
requirements  during  reprocurement  of  systems,  subsystems,  components,  spares,  and  services 
beyond  the  initial  production  contract  award,  and  during  post-production  support  to  facilitate 
technology  insertion  and  modernization  of  operational  weapons  systems. 

C5.3.2.2.2.  Systems  that  benefit  fi'om  a  PBBE  include  highly  interoperable 
systems,  high  tech/high  cost  systems,  high  return  on  investment  systems,  systems  requuing  a 
high  degree  of  logistics  readiness  and/or  technology  insertion  opportunity,  and/or  systems  with  a 
high  TOC  and/or  a  long  predicted  life. 

C5.3.3.  Metric  System.  The  PM  shall  use  the  metric  system  of  measurement  for  all 
elements  of  defense  systems  requiring  new  design,  unless  waived  by  the  MDA  as  not  in  the  best 
interest  of  the  government  (15  U.S.C.  205a-205k  (reference  (mr))  and  E.O.  12770  (reference 
(ssss))). 
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C5.3.4.  Insensitive  Munitions^.  All  munitions  and  weapons,  regardless  of  ACAT,  shall 
conform  to  insensitive  mimitions  (xmplanned  stimuli)  criteria  and  use  materials  consistent  with 
safety  and  interoperability  requirements  (see  subparagraphs  C5.2.3.5.10.  and  C5.2.3.5.1  !.)•  The 
requirements  validation  process  shall  determine  insensitive  munitions  requirements  and  keep 
them  current  throughout  the  acquisition  cycle.  Interoperability,  to  include  insensitive  mumtions 
policies,  shall  be  certified  per  CJCS  Instruction  3 170.0 IB  (reference  (f)).  Waivers  for 
munitions/weapons,  regardless  of  ACAT  level,  shall  require  JROC  approval.  The  ultimate 
objective  is  to  design  and  field  munitions  that  have  no  adverse  reaction  to  unplanned  stimuli, 
analogous  to  Hazard  Division  1.6  (see  TB  700-2  (reference  (tttt))). 

C5.3.5.  Value  Engineering.  The  PM  shall  apply  value  engineering  to  projects  and  programs 
per  41  U.S.C.  432  (reference  (uuuu))  and  0MB  Circular  A-131  (reference  (ww)).  The  PM 
shall  consider  an  incentive  approach  and/or  a  mandatory  approach  as  described  in  FAR  Part  48 
(reference  (wwww)).  The  value-engineering  program  may  include  both  internal  DoD  and 
contractor  activity. 

C5.3.6.  Precise  Time  and  Time  Interval.  To  ensure  uniformity  in  precise  time  and  time 
interval  operations.  Coordinated  Universal  Time,  as  determined  by  the  Master  Clock  at  the 
United  States  Naval  Observatory,  shall  be  the  DoD  systems  standard. 

C5.3.7.  Accessibility  Requirements.  PMs  shall  ensure  that,  where  appropriate,  system 
development  includes  accessibility  requirements  as  outlined  in  Section  508  of  the  Rehabilitation 
Act  of  1973  (29  U.S.C.  794d  (reference  (xxxx))).  All  electronic  and  information  technology, 
including  telecommunications,  software,  hardware,  web  sites,  printers,  fax  machines,  copiers, 
and  information  kiosks,  where  appropriate,  shall  include  requirements  to  ensure  people  with 
disabilities  are  able  to  use  the  system  and  have  access  to  the  information  or  data. 

C5.3.8.  Corrosion  Prevention  and  Control.  The  PM  shall  consider  and  implement  corrosion 
prevention  and  control  activities  to  minimize  the  impact  of  corrosion/material  deterioration 
throughout  the  system  life  cycle.  Corrosion  prevention  and  control  methods  include,  but  are  not 
limited  to,  the  use  of  effective  design  practices,  material  selection,  protective  finishes,  production 
processes,  packaging,  storage  environments,  protection  during  shipment,  and  maintenance 
procedures.  PMs  shall  establish  and  maintain  a  corrosion  prevention  and  control  reporting 


^  Not  applicable  to  ACAT  lA  programs. 
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system  for  data  collection  and  feedback,  and  use  it  to  adequately  address  corrosion  prevention 
and  control  logistic  considerations  and  readiness  issues. 
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C6.  CHAPTER  6 
INFORMATION  SUPERIORITY 


C6.1.  GENERAL 

Information  superiority  is  defined  as  the  capability  to  collect,  process,  and  disseminate  an 
uninterrupted  flow  of  information  while  exploiting  or  denying  an  adversary's  ability  to  do  the 
same.  Forces  attain  information  superiority  through  the  acquisition  of  systems  and  faimlies-of- 
systems  that  are  secure,  reliable,  interoperable,  and  able  to  communicate  across  a  umversal  IT 
infrastructure,  to  include  NSS.  This  IT  infrastructure  includes  the  data,  information,  processes, 
organizational  interactions,  skills,  and  analytical  expertise,  as  well  as  systems,  networks,  and 
information  exchange  capabilities.  Information  superiority  inherently  depends  on  program 
design,  but  equally  depends  on  the  readiness  of  the  implemented  technology  to  provide  direct 
user  capabilities  and  the  readiness  of  the  supporting  infrastructures  that  apply  these  technologies 
to  be  successfully  employed. 

C6.2.  INTELLIGENCE  SUPPORT 

C6.2.1.  Users  shall  base  acquisition  programs,  initiated  in  response  to  a  military  threat,  on 
authoritative  current  and  projected  threat  information.  The  intelligence,  requirements  generation, 
and  acquisition  management  communities  shall  collaborate  early  and  continuously  to  ensure  the 
use  of  timely,  valid,  threat  information.  This  collaboration  shall  include  joint  examination  of 
critical  intelligence  categories  that  could  significantly  influence  the  effective  operation  of  the 
deployed  system. 

C6.2.2.  Users  shall  assess  and  evaluate  information  superiority  requirements.  They  shall 
determine  the  vulnerability  of  IT,  including  NSS,  supporting  infrastructures,  and  the 
effectiveness  of  risk  mitigation  methods  to  reduce  vulnerability  to  an  acceptable  level. 

C6.2.3.  Threat  Validation.  For  acquisition  programs  subject  to  DAB  review,  DIA  shall 
validate  System  Threat  Assessments  and  other  threat  information,  including  that  contained  in 
program  documents.  For  other  than  DAB  programs,  the  MDA  shall  designate  the  approving 
agency. 

C6.2.4.  System  Threat  Assessment 

C6.2.4. 1 .  The  DoD  Components  shall  prepare  a  System  Threat  Assessment  to  support 
program  initiation.  They  shall  keep  the  assessment  current  and  in  a  validated  status  throughout 
the  acquisition  process.  DIA  shall  review  the  assessment  prior  to  all  milestone  decision  points. 
For  ACAT  ID  programs,  the  assessment  shall  be  system-specific  to  the  degree  of  system 
definition  available  at  the  time  of  the  assessment.  The  assessment  shall  address  the  projected 
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threat  at  IOC  and  at  IOC  plus  10  years.  The  DoD  Components  shall  structure  threat  assessments 
for  ACAT IC  programs  similarly,  but  the  ACAT IC  assessments  may  address  operationally 
related  systems,  when  practicable. 

C6.2.4.2.  The  System  Threat  Assessment  shall  include  the  following  minimum 
elements: 


C6.2.4.2.1.  An  executive  summary  to  include  the  key  intelligence  judgments  and 
significant  changes  in  the  threat  environment; 

C6.2.4.2.2.  The  mission  need  for  the  U.S.  system; 

C6.2.4.2.3.  A  system  description; 

C6.2.4.2.4.  Discussion  of  the  operational  threat  environment:  the  threat  to  be 
countered,  the  system  specific  threat,  reactive  threat,  and  technologically  feasible  threat;  and 

C6.2.4.2.5.  Critical  intelligence  categories,  and  the  intelligence  production 
requirements  supporting  these  critical  intelligence  categories,  developed  by  the  PM  early  in  the 
acquisition  process. 

C6.3.  INFORMATION  INTEROPERABILITY 

C6.3.1.  For  the  purposes  of  this  paragraph,  information  interoperability  means  the  exchange 
and  use  of  information  in  any  electronic  form.  Information  interoperability  enables  both 
effective  war  fighting  and  combat  support  operations,  both  within  the  Department  of  Defense 
and  with  external  activities  (e.g.,  within  the  federal  government  or  with  coalition  partners). 

CJCS  Instruction  3 170.0 IB  (reference  (Q)  requires  users  to  develop  an  interoperability  KPP  and 
identify  lERs.  The  ORD  sponsor  shall  develop  lERs  and  associated  interoperability  ^P  using 
mission-area  integrated  architectures  as  prescribed  in  DoD  Instruction  4630.8  (reference  (iiii)) 
and  CJCS  Instruction  6212.01B  (reference  (jjjj)). 

C6.3.2.  The  ORD  sponsor  shall  characterize  information  interoperability,  as  applicable, 
within  a  family  of  systems,  a  mission  area,  and  a  mission,  for  all  IT  systems,  including  NSS.  In 
developing  the  ORD,  the  ORD  sponsor  shall  consider  using  the  products  described  in  the  C4ISR 
Architecture  Framework  (renamed  the  DoD  Architecture  Framework  in  versions  2. 1  and  later) 
and  imiversal  resources  such  as  the  JTA.  The  ORD  sponsor  shall  apply  the  following  guidance 
to  information  interoperability: 

C6.3.2.1.  Manage,  verify  and  maintain  information  interoperability  throughout  the 
system  life  cycle;  and 
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C6.3.2.2.  Participate  in  interoperability  and  supportability  M&S  assessments  that  are 
performed  by  the  Military  Departments  or  Lead  Executive  Component  to  determine  the  level  of 
interoperability  between  systems  and  identify  incompatibilities. 

C6.3.3.  The  interoperability  and  supportability  of  IT  acquisition  programs,  including  NSS, 
shall  comply  with  DoD  Directive  4630.5  (reference  (hhhh)),  DoD  Instruction  4630.8  (reference 
(iiii)),  CJCS  Instruction  3 170.0 IB  (reference  (h)),  and  CJCS  Instruction  62 12.0 IB  (reference 
(iijj)).  (Pub.  L.  104-106  (1996),  Section  5123  (reference  (e))  and  44  U.S.C.  3506  (reference  (c))) 

C6.4.  COMMAND.  CONTROL.  COMMUNICATIONS.  COMPUTERS,  AND 
INTELLIGENCE  SUPPORT 

C6.4.1.  The  DoD  Components  shall  identify  and  evaluate  IT,  including  NSS,  infrastructure 
and  support  requirements  early  in,  and  throughout,  each  program's  life  cycle.  They  shall 
consider  these  requirements  in  the  analysis  of  alternatives  and  in  developing  and  refining 
operational  requirements.  They  shall  also  identify  these  requirements  to  support  transition 
decisions  for  all  advanced  concept  technology  demonstrations. 

C6.4.2.  The  DoD  Components  shall  develop  C4ISPs  for  programs  in  all  acquisition 
categories  when  they  connect  in  any  way  to  the  communications  and  information  infrastructure. 
This  includes  IT  systems,  including  NSS,  and  all  infrastructure  programs.  Unless  the  program  is 
on  the  special  interest  list,  C4ISPs  for  upgrades  to  existing  systems  shall  be  limited  to  the  scope 
of  the  upgrade  as  defined  in  the  acquisition  program,  even  when  there  is  no  C4ISP  for  the 
existing  system.  The  DoD  Components  shall  keep  the  C4ISP  current  throughout  the  program’s 
acquisition  process.  The  C4ISP  shall  be  formally  reviewed  at  each  milestone,  at  each  block  in  an 
evolutionary  acquisition,  at  decision  reviews,  as  appropriate,  and  whenever  the  concept  of 
operations  or  IT,  including  NSS,  support  requirements  change. 

C6.4.3.  ASD(C3I)  shall  review  all  C4ISPs  for  ACAT I  and  ACAT  lA  programs,  and  for 
special  interest  programs  designated  by  ASD(C3I).  Components  shall  develop  internal 
procedures  for  the  review  of  C4ISPs.  Should  interoperability  issues  arise  between  ACAT  I  or  lA 
and  less  than  ACAT  I  or  lA  programs,  DoD  Components  shall,  if  requested,  be  able  to  provide 
the  C4ISP  for  the  less  than  ACAT  I  or  lA  program  to  ASD  (C3I)  to  support  issue  resolution. 

C6.4.4.  The  Department  shall  address  and  resolve  critical  interoperability  and  supportability 
concerns  that  surface  during  C4ISP  reviews  either  prior  to  milestone  or  decision  approval  or 
through  tasking  in  the  Acquisition  Decision  Memorandum  (ADM).  The  initial  C4ISP  is  due  at 
program  initiation.  Appendix  5  contains  C4ISP  preparation  and  review  procedures,  formats,  and 
timelines. 

C6.4.5.  The  DoD  Components  shall  tailor  C4ISPs  based  on  the  complexity,  scale,  mission 
criticality,  or  other  unique  aspects  of  the  program  or  system's  IT,  including  NSS,  support  and 
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interface  requirements.  At  each  decision  point,  C4ISPs  shall  contain  progressively  more  detailed 
and  specific,  time-phased  descriptions  of  the  types  of  information  needed;  operational,  systems, 
and  technical  architecture  requirements;  lERs;  spectrum,  supportability,  security,  connectivity, 
and  interoperability  issues;  and  IT,  including  NSS,  infi'astmcture  and  support  shortfalls. 
Infrastructure  programs  shall  also  prepare  C4ISPs.  The  MDA,  with  advice  from  the  appropriate 
CIO,  may  waive  C4ISP  preparation  if  the  Requirements  Authority  has  previously  waived  the 
requirement  for  an  interoperability  KPP  in  the  ORD. 

C6.5.  ELECTROMAGNETIC  ENVIRONMENTAL  EFFECTS  (E3~)  AND  SPECTRUM 
SUPPORTABILITY 

C6.5.1 .  The  PM  shall  design  all  electric  or  electronic  systems/equipment  to  be  mutually 
compatible  with  other  electric  or  electronic  systems/equipment  and  the  operational 
electromagnetic  environment.  All  systems  shall  meet  operational  performance  requirements. 

The  PM  shall  design  ordnance  and  associated  systems  to  preclude  inadvertent  ignition,  and  to 
perform  effectively,  during  or  after  exposure  to  the  operational  electromagnetic  environment. 

For  additional  information,  see  DoD  Directive  3222.3  (reference  (yyyy)). 

C6.5.2.  The  following  applies  to  all  electromagnetic  spectrum-dependent  systems  and 
equipment,  including  commercial  and  non-developmental  items: 

C6.5.2. 1 .  In  accordance  with  0MB  Circular  A-1 1  (reference  (b)),  PMs  shall  determine 
system  spectrum  supportability  prior  to  initiating  cost  estimates  for  development  or  procurement. 

C6.5.2.2.  Systems  shall  comply  with  statutory  spectrum  supportability  management 
requirements  (47  U.S.C.  Chapter  8  (reference  (zzzz)))  and  the  National  Telecommunications  and 
Information  Administration  Manual  of  Regulations  and  Procedures  for  Federal  Radio  Frequency 
Management  (47  C.F.R.  300.1  (reference  (aaaaa)))  and  shall  address  requirements  to  achieve 
appropriate  international  spectrum  supportability. 

C6.5.2.3.  Design  criteria  for  systems  that  use  the  electromagnetic  spectrum  (spectmm 
dependent)  must  take  into  consideration  other  current  and  future  DoD  spectrum  dependent 
systems,  as  well  as,  current  and  projected  govemment/non-DoD  and  civil  spectrum  use. 

C6.5.2.4.  DoD  components  shall  obtain  radio  frequency  spectrum  guidance  from  the 
Military  Communications-Electronics  Board  (DoD  Directive  4650. 1  (reference  (bbbbb))). 

C6.5.3.  The  PM  shall  forward  requirements  for  foreign  spectrum  support  (i.e.,  DD  Form 
1494  via  U.S.  Supplement  1,  Allied  Communication  Publication  190  (reference  (ccccc)))  through 
established  channels  (e.g..  Service  Spectrum  Management  Organization)  to  the  Military 
Communications-Electronics  Board  to  initiate  host  nation  coordination  with  nations  where 
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deployment  of  the  system  or  support  equipment  is  planned  for  outside  of  the  continental  United 
States. 

C6.6.  INFORMATION  ASSURANCE 

C6.6.1.  PMs  shall  manage  and  engineer  information  systems  using  the  best  processes  and 
practices  known  to  reduce  security  risks,  including  the  risks  to  timely  accreditation.  Per  DoD 
Instruction  5200.40  (reference  (iii)),  they  shall  address  information  assurance  requirements 
throughout  the  life  cycle  of  all  DoD  systems.  The  PM  shall  incorporate  approved  CRD-derived 
and  ORD-derived  information  assurance  requirements  into  program  design  activities  to  ensure 
appropriate  availability,  integrity,  authentication,  confidentiality,  and  non-repudiation  of  program 
and  system  information  and  the  information  systems  themselves,  as  specified  in  the  applicable 
SSAA.  PMs  shall  also  provide  for  the  survivability  of  information  by  incorporating  protection, 
detection,  reaction,  and  reconstitution  capabilities  into  the  system  design,  as  appropriate,  and  as 
allocated  in  SSAAs. 

C6.6.2.  Accordingly,  for  each  information  system  development,  PMs  shall: 

C6.6.2. 1 .  Conduct  a  system  risk  assessment  based  on  system  criticality,  threat,  and 
vulnerabilities; 

C6.6.2.2.  Incorporate  appropriate  countermeasures; 

C6.6.2.3.  Demonstrate  the  effectiveness  of  those  countermeasures  through  the 
certification  process  conducted  in  accordance  with  DoD  Instruction  5200.40  (reference  (iii)) 
during  DT&E; 

C6.6.2.4.  Ensure  that  the  responsible  designated  approving  authority  accredits  the 
system;  and, 

C6. 6.2.5.  Incorporate  existing,  or  develop  new,  protection  profiles  to  consolidate 
security-related  requirements  and  provide  effective  management  oversight  of  the  overall  security 
program. 

C6.7.  TECHNOLOGY  PROTECTION 

C6.7.1.  PMs  shall  identify  critical  elements  of  their  program,  referred  to  as  Critical  Program 
Information  (CPI).  This  applies  to  any  acquisition  program  that  requires  protection  to  prevent 
unauthorized  disclosure  or  inadvertent  transfer  of  leading-edge  technologies  and  sensitive  data  or 
systems,  otherwise  referred  to  as  “compromise.”  CPI  may  be  identified  during  the  requirements 
generation  process,  may  be  integral  to  the  program,  may  be  inherited  from  a  supporting  program, 
or  may  result  from  acquisition  techniques  such  as  flexible  technology  insertion.  For  programs 
with  CPI,  the  PM  shall  notify  the  DoD  Component  servicing  counterintelligence  agency 
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technology  protection  program  manager  of  the  identified  CPI,  and  develop  a  program  protection 
plan  prior  to  Milestone  B. 

C6.7.2.  Each  program  shall  have  an  integrated,  comprehensive,  and  coherent  program 
protection  plan  and  process  over  the  entire  system  life  cycle.  The  adequacy  and  effectiveness  of 
protection  shall  be  reviewed  at  each  milestone  or  decision  point.  The  PM  shall  prioritize 
identified  protection  vulnerabilities  based  upon  the  mission  consequences  if  the  CPI  is  lost  or 
compromised,  allowing  a  foreign  interest  to  exploit  the  CPI.  Technology  protection  planning 
and  development  of  the  program  protection  plan  shall  begin  early  in  the  acquisition  life  cycle. 
The  following  considerations  apply: 

C6.7.2.1.  Attempt  to  shape  or  influence  the  projected  threat  environment  in  a  direction 
favorable  to  U.S.  national  security  interests. 

C6.7.2.2.  Systems  of  extraordinary  importance  to  the  national  security,  such  as  space, 
strategic,  and  C4ISR  systems,  shall  have  particularly  stringent  protection  requirements,  planning, 
and  oversight  due  to  the  broad,  serious,  and  enduring  consequences  of  degradation  or  loss  to  the 
National  Command  Authorities  and  combatant  commands. 

C6.7.2.3.  The  DoD  Component  counterintelligence  organizations  shall  provide  the  PM 
with  information  concerning  the  foreign  intelligence  and  other  related  threats  to  the  acquisition 
program  with  CPI. 

C6.7.2.4.  Security  organizations  shall  identify  system  vulnerabilities  and  recommend 
cost-effective  security  measures  using  risk  management  evaluations. 

C6.7.2.5.  Coimterintelligence  organizations  shall  offer  a  variety  of  tailored  services  to 
address  threats  posed  by  foreign  intelligence  services  to  an  acquisition  program.  The  program 
protection  plan  shall  identify  those  counterintelligence  services. 

C6.7.2.6.  DoD  Component  counterintelligence  organizations  will  identify  a 
counterintelligence  point  of  contact  for  each  program  with  CPI.  Throughout  the  life  of  the 
program,  based  on  field  counterintelligence  activities  supporting  the  program,  the 
counterintelligence  point  of  contact  shall  provide  updated  threat  and  other  counterintelligence 
information  to  the  PM. 

C6.7.2.7.  As  technology  allows,  systems  engineering  activities  shall  use  encryption, 
packaging  or  bundling,  and  other  tamper-proofing  techniques  to  maximize  CPI  protection.  The 
PM  shall  consider  anti-tamper  techniques  intended  to  prevent  or  delay  exploitation  of  military 
critical  technologies  in  weapons  systems. 
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C6.7.3.  The  program  protection  plan  shall  address  information  systems  security,  defensive 
information  warfare,  TEMPEST,  personnel  security,  classification  management,  physical 
security,  operations  seciuity,  technology  transfer,  counterintelligence,  and  international  security 
requirements.  Systems  protection  shall  include:  Information  Assurance,  Information  Security, 
Anti-Terrorism,  Coimter-Terrorism,  Force  Protection,  Continuity  of  Operations,  Physical 
Security,  Information  Security,  Operations  Security,  Threat  Waming/Attack  Assessment, 
Personnel  Security,  Foreign  Disclosure,  Technology  Transfer,  etc. 

C6.7.4.  The  PM  shall  report  a  finding  that  no  CPI  exists  to  the  MDA,  if  so  determined. 

DoD  Directive  5200.39  (reference  (ddddd)),  DoD  5200. 1-M  (reference  (zzz)),  and  the  DoD 
Technology  Protection  Handbook  have  more  on  technology,  protection,  and  development  of  the 
program  protection  plan  and  anti-tamper. 

C6.7.5.  Anti-Tamper  Measures 

C6.7.5. 1 .  The  PM  shall  consider  anti-tamper  measures  for  use  on  any  system  with  CPI, 
developed  with  allied  partners,  likely  to  be  sold  or  provided  to  U.S.  allies  and  fiiendly  foreign 
governments,  or  likely  to  fall  into  enemy  hands.  The  PM  shall  document  the  analysis  and 
recommendation  to  use  or  not  to  use  anti-tamper  measures  in  a  classified  annex  to  the  program 
protection  plan,  and  report  findings  to  the  MDA  at  Milestone  B  and  subsequent  milestones.  The 
MDA  shall  consider  for  approval,  the  PM’s  recommendation  to  implement  or  not  to  implement 
anti-tamper  measures. 

C6.7.5.2.  At  Milestone  B,  the  PM  shall  address  implementation  of  anti-tamper 
measures,  and,  in  conceptual  terms,  the  demonstration  of  these  measiues  through  working 
prototypes.  The  anti-tamper  annex  to  the  program  protection  plan  at  Milestone  B  shall  include 
the  following: 

C6.7.5.2.1.  A  list  of  critical  technologies; 

C6.7.5.2.2.  A  threat  analysis; 

C6.7.5.2.3.  Identified  vulnerabilities;  and 

C6.7.5.2.4.  A  preliminary  anti-tamper  requirement. 

C6.7.5.3.  At  Milestone  C,  the  PM  shall  address  how  anti-tamper  measures  have  been 
demonstrated,  and  how  they  will  be  tested  during  DT  and  OT,  and  made  ready  for  production. 

C6.7.5.3. 1 .  The  anti-tamper  annex  to  the  program  protection  plan  at  Milestone  C 
shall  include  the  following: 

C6.7.5.3.1.1.  All  deliverables  from  Milestone  B  and  applicable  updates; 
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C6.7.5.3.1.2.  An  analysis  of  anti-tamper  methods  that  apply  to  the  system, 
including  cost/benefit  assessments; 

C6.7.5.3.1.3.  An  explanation  of  which  anti-tamper  method(s)  will  be 

implemented;  and 

C6.7.5.3.1.4.  Planning  for  validation  of  the  anti-tamper  implementation. 

C6.7.5.3.2.  The  MDA  shall  review  the  validation  planning  at  Milestone  C. 

C6.7.5.4.  Developmental  test  and  evaluation  shall  verify  implementation  of  anti-tamper 
measures.  During  initial  system  production,  the  Department’s  anti-tamper  executive  agent  shall 
validate  anti-tamper  measures  on  actual  or  representative  system  components  provided  by  the 
PM.  The  anti-tamper  executive  agent  shall  report  validation  results  to  the  appropriate  SAE  and 
USD(AT&L)  at  the  Full-Rate  Production  decision  review. 

C6. 7.5.5.  Anti-tamper  measures  shall  apply  throughout  the  life  cycle  of  the  system. 
Maintenance  instructions  and  technical  orders  shall  clearly  indicate  that  anti-tamper  measures 
have  been  implemented;  indicate  the  level  at  which  maintenance  is  authorized,  and  include 
warnings  that  damage  may  occur  if  improper  or  unauthorized  maintenance  is  attempted.  To 
protect  critical  technologies,  it  may  be  necessary  to  limit  the  level  and  extent  of  maintenance  a 
foreign  customer  may  perform.  This  may  mean  that  maintenance  involving  the  anti-tamper 
measures  will  be  accomplished  only  at  the  contractor  or  U.S.  Government  facility  in  the  U.S.  or 
overseas.  Such  maintenance  restrictions  may  be  no  different  than  those  imposed  on  U.S. 
Government  users  of  anti-tamper  protected  systems.  Contracts,  purchase  agreements, 
memoranda  of  understanding,  memoranda  of  agreement,  letters  of  agreement,  or  other  similar 
documents  shall  state  such  maintenance  and  logistics  restrictions.  When  a  contract  that  includes 
anti-tamper  protection  requirements  and  associated  maintenance  and  logistics  restrictions  also 
contains  a  warranty  or  other  form  of  performance  guarantee,  the  contract  terms  and  conditions 
shall  establish  that  unauthorized  maintenance  or  other  unauthorized  activities: 

C6.7.5.5. 1 .  Shall  be  regarded  as  hostile  attempts  to  exploit  or  reverse  engineer  the 
weapon  system  or  the  anti-tamper  measure  itself  and 

C6.7.5.5.2.  Shall  void  the  warranty  or  performance  guarantee. 

C6.8.  IT  REGISTRATION 

All  mission  critical  and  mission  essential  information  systems  shall  be  registered  with  the  DoD 
CIO  in  accordance  with  procedures  in  Appendix  7,  before  Milestone  B  approval  or  program 
initiation,  whichever  is  earlier.  The  information  required  to  be  submitted  as  part  of  this 
registration  shall  be  updated  not  less  than  quarterly. 
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Cl.  CHAPTER? 

PROGRAM  DECISIONS.  ASSESSMENTS.  AND  PERIODIC  REPORTING 
C7.1.  PURPOSE 

This  Chapter  establishes  mandatory  policies  and  procedures  for  making  major  pro^m  decisions 
for  ACAT  ID  and  ACAT  lAM  programs.  It  also  addresses  periodic  reporting  requirements. 

C7.2.  DECISION  POINTS 


There  are  three  types  of  decision  points:  milestones,  decision  reviews,  and  interim  progress 
reviews.  Each  decision  point  results  in  a  decision  to  initiate,  continue,  advance,  or  terminate  a 
project  or  program  work  effort  or  phase.  The  review  associated  with  each  decision  point  shall 
typically  address  program  progress  and  risk,  affordability,  program  trade-offs,  acquisition 
strategy  updates,  and  the  development  of  exit  criteria  for  the  next  phase  or  effort.  The  type  and 
number  of  decision  points  shall  be  tailored  to  program  needs.  The  MDA  shall  approve  the 
program  structure  as  part  of  the  acquisition  strategy. 

C7.2.1.  Milestone  decision  points  shall  initiate  programs  and  authorize  entry  into  the  major 
acquisition  process  phases:  Concept  and  Technology  Development,  System  Development  and 
Demonstration,  and  Production  and  Deployment.  The  information  specified  in  DoD  Instruction 
5000.2,  enclosure  3  (reference  (a)),  shall  support  milestone  reviews. 

C7.2.2.  Decision  reviews  shall  assess  program  progress  and  authorize  continued  program 
development. 

C7.2.2. 1 .  Programs  beginning  in  the  concept  exploration  work  effort  of  the  Concept 
and  Technology  Development  Phase  shall  require  a  decision  review  to  determine  whether  or  not 
the  concept  is  ready  to  be  pursued  in  component  advanced  development.  If  the  work  content 
typically  associated  with  component  advanced  development  has  been  completed,  a  Milestone  B 
review  may  substitute  for  this  decision  review. 

C7.2.2.2.  The  MDA  shall  schedule  a  Full-Rate  Production  and  Deployment  Decision 
Review  during  the  Production  and  Deployment  Phase  to  consider  the  results  of  production 
qualification  testing  and  lOT&E  and  to  authorize  full-rate  production  and  deployment. 

C7.2.2.3.  Decision  reviews  are  designed  to  be  streamlined  reviews  and  shall  require 
only  the  information  specified  by  the  MDA  or  as  required  by  statute.  The  information  required 
to  support  the  component  advanced  development  and  fiill-rate  production  and  deployment 
decision  reviews  shall  be  tailored  to  support  the  review  and  be  consistent  with  and  not  exceed  the 
information  specified  in  DoD  Instruction  5000.2,  enclosure  3  (reference  (a)). 
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Cl. 23.  Interim  progress  reviews  shall  assess  program  progress  within  the  System 
Development  and  Demonstration  phase.  This  review  shall  only  require  information  as  specified 
by  the  MDA. 

Cl 3.  EXECUTIVE  REVIEW  PROCEDURES 


The  following  paragraphs  detail  procedures  for  the  assessment  reviews  associated  with  major 
decision  points. 

C7.3.1.  Defense  Acquisition  Board  (DAB)  Review 

C7.3.1.1.  The  DAB  shall  advise  the  Under  Secretary  of  Defense  (Acquisition, 
Technology,  and  Logistics)  on  critical  acquisition  decisions.  The  Under  Secretary  of  Defense 
(Acquisition,  Technology,  and  Logistics)  shall  chair  the  DAB,  and  the  Vice  Chairman  of  the 
Joint  Chiefs  of  Staff  shall  serve  as  vice-chair.  DAB  membership  shall  comprise  the  following 
executives:  Under  Secretary  of  Defense  (Comptroller);  Under  Secretary  of  Defense  (Policy); 
Under  Secretary  of  Defense  (Personnel  &  Readiness);  Assistant  Secretary  of  Defense 
(Command,  Control,  Communications,  and  Intelligence)/Department  of  Defense  Chief 
Information  Officer;  Director,  Operational  Test  and  Evaluation;  and  the  Secretaries  of  the  Army, 
Navy,  and  the  Air  Force.  United  States  Joint  Forces  Command  shall  be  available  to  comment  on 
interoperability  and  integration  issues  that  the  JROC  forwards  to  the  DAB.  The  DAE  may  ask 
other  department  officials  to  participate  in  reviews,  as  required. 

C7.3.1.2.  The  reviews  shall  focus  on  key  principles  to  include  interoperability,  time- 
phased  requirements  related  to  an  evolutionary  approach,  and  demonstrated  technical  maturity. 
DAB  reviews,  and  milestones  in  particular,  t5^ically  require  extensive  supporting 
documentation,  per  enclosure  3  of  reference  (a). 

C7.3.1.3.  The  Defense  Acquisition  Executive  shall  conduct  DAB  reviews  at  major 
program  milestones  and  at  the  Full-Rate  Production  Decision  Review  (if  not  delegated  to  the 
CAE),  and  at  other  times,  as  necessary.  An  ADM  shall  document  the  decision(s)  resulting  from 
the  review. 

C7.3.1.4.  The  PM  shall  brief  the  acquisition  program  to  the  DAB  and  specifically 
emphasize  technology  maturity,  risk  management,  affordability,  critical  program  information, 
technology  protection,  and  rapid  delivery  to  the  user.  The  PM  shall  address  any  interoperability 
and  supportability  requirements  linked  to  other  systems,  and  indicate  whether  those  requirements 
will  be  satisfied  by  the  acquisition  strategy  under  review.  If  the  program  is  part  of  a  system-of- 
systems  architecture,  the  PM  shall  brief  the  DAB  in  that  context.  If  the  architecture  includes  less 
than  ACAT I  programs  that  are  key  to  achieving  the  expected  operational  capability,  the  PM 
shall  also  discuss  the  status  of  and  dependence  on  those  programs. 
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C1.7>2.  DoD  CIO  Reviews 

C7.3.2.1.  DoD  CIO  Reviews  shall  provide  the  forum  for  ACAT  lAM  milestones,  for 
deciding  critical  ACAT  LAM  issues  when  they  cannot  be  resolved  at  the  OIPT  level,  and  for 
enabling  the  execution  of  the  DoD  CIO’s  acquisition-related  responsibilities  for  IT,  including 
NSS,  under  the  Clinger-Cohen  Act  and  Title  10  (references  (ppp)  and  (eeeee)).  Wherever 
possible,  these  reviews  shall  take  place  in  the  context  of  the  existing  IPT  and  acquisition 
milestone  review  process.  Where  appropriate,  an  ADM  shall  typically  document  the  decision(s) 
resulting  from  the  review. 

C7.3.2.2.  To  meet  the  DoD  CIO’s  acquisition-related  responsibilities  under  references 
(ppp)  and  (eeeee),  these  reviews  shall  focus  on  key  principles  such  as: 

C7.3.2.2.1.  Support  of  mission  needs  as  described  in  Defense  Planning  Guidance, 
Joint  Vision  2020,  the  DoD  Information  Management  Strategic  Plan,  the  operational  view  of  the 
approved  Global  Information  Grid  (GIG)  Integrated  Architecture,  and  the  approved  GIG  CRD. 

C7.3.2.2.2.  Compliance  with  GIG-related  policies  and  the  approved  GIG 
Integrated  Architecture. 

C7.3.2.2.3.  Interoperability  implementation  plans  and  status  implications  of 
program  and  budget  decisions/altematives. 

C7. 3.2.3.  Principal  participants  at  DoD  CIO  reviews  shall  include  (as  appropriate  to  the 
issue  being  examined)  the  following  department  officials:  the  Deputy  DoD  CIO;  IT  OIPT 
Leader;  ACAT  ID  OIPT  Leaders;  Cognizant  PEO(s)  and  PM(s);  Co^izant  OSD  PSA;  CAEs 
and  CIOs  of  the  Army,  Navy,  and  Air  Force.  Participants  shall  also  include  (as  appropriate  to 
the  issue  being  examined)  executive-level  representatives  from  the  following  organizations: 
Office  of  USD(AT&L);  Office  of  the  Under  Secretary  of  Defense  (Comptroller);  Office  of  the 
Joint  Chiefs  of  Staff;  Office  of  DOT&E;  Office  of  the  Director,  PA&E;  and  Defense  Information 
Systems  Agency. 

C7.3.2.4.  The  DoD  CIO  may  ask  other  department  officials  to  participate  in  reviews,  as 

required. 

C7.4.  EXIT  CRITERIA 

C7.4.1.  MDAs  shall  use  exit  criteria  to  establish  goals  for  ACAT  I  (10  USC  2220(a)(1) 
(reference  (h)))  and  ACAT  LA  (Pub.  L.  104-106  (1996),  Section  5123  (reference  (e)))  programs 
during  an  acquisition  phase.  At  each  milestone  decision  point  and  at  each  decision  review,  the 
PM,  in  collaboration  with  the  IPT,  shall  develop  and  propose  exit  criteria  appropriate  to  the  next 
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phase  or  effort  of  the  program.  The  OIPT  will  review  the  proposed  exit  criteria  and  recommend 
exit  criteria  to  the  MDA.  The  MDA  shall  approve  and  publish  exit  criteria  in  the  ADM. 

C7.4.2.  Phase-specific  exit  criteria  normally  track  progress  in  important  technical,  schedule, 
or  management  risk  areas.  Unless  waived  or  modified  by  the  MDA,  exit  criteria  must  be 
substantially  satisfied  for  the  program  to  continue  with  additional  activities  within  an  acquisition 
phase  or  to  proceed  into  the  next  acquisition  phase,  depending  on  the  decision  with  which  they 
are  associated.  Exit  criteria  shall  not  be  part  of  the  APB  and  are  not  intended  to  repeat  or  replace 
APB  requirements  or  the  entrance  criteria  specified  in  DoD  Instruction  5000.2  (reference  (a)). 
They  shall  not  cause  program  deviations.  The  DAES  (see  paragraph  C7.15.3.  and  Appendix  1) 
shall  report  the  status  of  exit  criteria. 

C7.5.  TECHNOLOGY  MATURITY 

C7.5.1.  Technology  maturity  shall  measure  the  degree  to  which  proposed  critical 
technologies  meet  program  objectives.  Technology  maturity  is  a  principal  element  of  program 
risk.  A  technology  readiness  assessment  shall  examine  program  concepts,  technology 
requirements,  and  demonstrated  technology  capabilities  to  determine  technological  matunty. 

C7.5.2.  The  PM  shall  identify  critical  technologies  via  the  WBS  (see  paragraph  C5.3.1.). 
Technology  readiness  assessments  for  critical  technologies  shall  occur  sufficiently  prior  to 
milestone  decision  points  B  and  C  to  provide  useful  technology  maturity  information  to  the 
acquisition  review  process. 

C7.5.3.  The  DoD  Component  Science  and  Technology  (S&T)  Executive  shall  direct  the 
technology  readiness  assessment  and,  for  ACAT  ID  and  ACAT  lAM  programs,  submit  the 
findings  to  the  CAE  who  shall  submit  his  or  her  report  to  the  DUSD(S&T)  with  a  recommended 
technology  readiness  level  (TRL)  (or  some  equivalent  assessment)  for  each  critical  technology. 
When  the  Component  S&T  Executive  submits  his  or  her  findings  to  the  CAE,  he  or  she  shall 
provide  the  DUSD(S&T)  an  information  copy  of  those  findings.  In  cooperation  with  the 
Component  S&T  Executive  and  the  program  office,  the  DUSD(S&T)  shall  evaluate  the 
technology  readiness  assessment  and,  if  he/she  concurs,  forward  findings  to  the  OIPT  leader  and 
DAB.  If  the  DUSD(S&T)  does  not  concur  with  the  technology  readiness  assessment  findings,  an 
independent  technology  readiness  assessment,  imder  the  direction  of  the  DUSD(S&T),  shall  be 
required. 

C7.5.4.  TRL  descriptions  appear  at  Appendix  6.  TRLs  enable  consistent,  uniform, 
discussions  of  technical  maturity,  across  different  types  of  technologies.  Decision  authorities 
shall  consider  the  recommended  TRLs  (or  some  equivalent  assessment  methodology,  e.g., 
Willoughby  templates)  when  assessing  program  risk.  TRLs  are  a  measure  of  technical  maturity. 
They  do  not  discuss  the  probability  of  occurrence  (i.e.,  the  likelihood  of  attaining  required 
maturity)  or  the  impact  of  not  achieving  technology  maturity. 
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Cl. 6.  INTEGRATED  PRODUCT  TEAMS  flPTS)  IN  THE  OVERSIGHT  AND  REVIEW 
PROCESS 

C7.6.1.  Defense  acquisition  works  best  when  all  of  the  Department's  Components  work 
together.  Cooperation  and  empowerment  are  essential.  The  Department's  acquisition 
community  shall  implement  the  concepts  of  IPPD  and  IPTs  as  extensively  as  possible. 

C7.6.2.  IPTs  are  an  integral  part  of  the  defense  acquisition  oversight  and  review  process. 

For  ACAT  ID  and  LAM  programs,  there  are  generally  two  levels  of  IPT:  the  OIPT  and  WIPT(s). 
Each  program  shall  have  an  OIPT  and  at  least  one  WIPT.  WIPTs  shall  focus  on  a  particular 
topic  such  as  cost/performance,  test,  or  contracting.  An  Integrating  IPT  (IIPT)  (which  is  a 
WIPT)  shall  coordinate  WIPT  efforts  and  cover  all  topics  not  otherwise  assigned  to  another  IPT. 
IPT  participation  is  the  primary  way  for  any  organization  to  participate  in  the  acquisition 
program. 

C7.6.3.  Industry  Participation 

C7.6.3.1.  Industry  representatives  may  be  invited  to  a  WIPT  or  IIPT  meeting  to  provide 
information,  advice,  and  recommendations  to  the  IPT;  however,  the  following  policy  shall 
govern  their  participation. 

C7.6.3.1.1.  Industry  representatives  shall  not  be  formal  members  of  the  IPT. 

C7.6.3. 1 .2.  Industry  participation  shall  be  consistent  with  FACA  (reference  (cc)). 

C7. 6.3. 1.3.  They  may  not  be  present  during  IPT  deliberations  on  acquisition 
strategy  or  competition  sensitive  matters,  nor  during  any  other  discussions  that  would  give  them 
a  marketing  or  competitive  advantage. 

C7. 6.3. 1.4.  At  the  beginning  of  each  meeting,  the  IPT  chair  shall  introduce  each 
industry  representative,  including  their  affiliation,  and  their  purpose  for  attending. 

C7.6.3.1 .5.  The  chair  shall  inform  the  IPT  members  of  the  need  to  restrict 
discussions  while  industry  representatives  are  in  the  room,  and/or  the  chair  shall  request  the 
industry  representatives  to  leave  before  matters  are  discussed  that  are  inappropriate  for  them  to 
hear. 


C7.6.3.1.6.  Support  contractors  may  participate  in  WIPTs  and  IIPTs,  but  they  may 
not  commit  the  organization  they  support  to  a  specific  position.  The  organizations  they  support 
are  responsible  for  ensuring  the  support  contractors  are  employed  in  ways  fliat  do  not  create  the 
potential  for  an  organizational  conflict  of  interest. 
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Cl. 6.2)2.  Given  the  sensitive  nature  of  OIPT  discussions,  neither  industry 
representatives  nor  support  contractors  shall  participate  in  OIPT  discussions.  However,  the 
OIPT  leader  may  permit  contractors  to  make  presentations  to  the  OIPT  when  such  views  will 
better  inform  the  OIPT,  and  will  not  involve  the  contractors  directly  in  government  decision 
making. 

C7.6.4.  Overarching  IPT  Procedures  and  Assessments 

C7.6.4.1 .  All  ACAT  ID  and  lAM  programs  shall  have  an  OIPT  to  provide  assistance, 
oversight,  and  review  as  the  program  proceeds  through  its  acquisition  life  cycle.  An  appropriate 
official  within  OSD,  typically  the  Director  of  Strategic  and  Tactical  Systems  or  the  Principal 
Director,  Command,  Control,  Communications,  Intelligence,  Surveillance,  and  Reconnaissance 
&  Space,  shall  lead  the  OIPT  for  ACAT  ID  programs.  The  Deputy  DoD  CIO  or  designee  shall 
lead  the  OIPT  for  ACAT  lAM  programs.  The  OIPT  for  ACAT  lAM  programs  is  called  the  IT 
OIPT.  OIPTs  shall  comprise  the  PM,  PEO,  Component  Staff,  Joint  Staff,  and  OSD  staff 
involved  in  oversight  and  review  of  the  particular  ACAT  ID  or  lAM  program. 

C7.6.4.2.  The  OIPT  shall  form  upon  departmental  intention  to  start  an  acquisition 
program.  The  OIPT  shall  charter  the  IIPT  and  WIPTs.  The  OIPT  shall  consider  the 
recommendations  of  the  IIPT  regarding  the  appropriate  milestone  for  program  initiation  and  the 
minimum  information  needed  for  the  program  initiation  milestone  review.  OIPTs  shall  meet, 
thereafter,  as  necessary  over  the  life  of  the  program.  The  OIPT  leader  shall  act  to  resolve  issues 
when  requested  by  any  member  of  the  OIPT,  or  when  so  directed  by  the  MDA.  The  goal  is  to 
resolve  as  many  issues  and  concerns  at  the  lowest  level  possible,  and  to  expeditiously  escalate 
issues  that  need  resolution  at  a  higher  level.  The  OIPT  shall  bring  only  the  highest-level  issues 
to  the  MDA  for  decision. 

C7.6.4.3.  The  OIPT  shall  normally  convene  two  weeks  before  a  planned  decision  point. 
It  shall  assess  the  information  and  recommendations  that  the  MDA  will  receive,  in  the  same 
context,  and  to  the  same  ACAT  level.  It  shall  also  assess  family-of-system  or  system-of-system 
capabilities  within  mission  areas  in  support  of  mission  area  operational  architectures  developed 
by  the  Joint  Staff.  If  the  program  includes  a  pilot  project,  such  as  TOC  Reduction,  the  PM  shall 
report  the  status  of  the  project  to  the  OIPT.  The  OIPT  shall  then  assess  progress  against  stated 
goals.  The  PM's  briefing  to  the  OIPT  shall  specifically  address  interoperability  and 
supportability  (including  spectrum  supportability)  with  other  systems,  anti-tamper  provisions, 
and  indicate  whether  those  requirements  will  be  satisfied  by  the  acquisition  strategy  under 
review.  If  the  program  is  part  of  a  family-of-systems  architecture,  the  PM  shall  brief  the  OIPT  in 
that  context.  If  the  architecture  includes  less  than  ACAT  I  programs  that  are  key  to  achieving  the 
expected  operational  capability,  the  PM  shall  also  discuss  the  status  of  and  dependence  on  those 
programs.  The  OIPT  leader  shall  recommend  to  the  MDA  whether  the  anticipated  review  should 
go  forward  as  planned. 
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C7.6.4.4.  For  ACAT  ID  decision  points,  the  OIPT  leader  shall  provide  the  DAB  chair, 
principals,  and  advisors  an  integrated  assessment  using  information  gathered  through  the  IPT 
process.  The  leader’s  assessment  shall  focus  on  core  acquisition  management  issues  and  shall 
consider  independent  assessments,  including  technology  readiness  assessments,  which  the  OIPT 
members  normally  prepare.  These  assessments  typically  occur  in  context  of  the  OIPT  review, 
and  shall  be  reflected  in  the  OIPT  leader’s  report.  There  shall  be  no  surprises  at  this  point— all 
team  members  shall  work  issues  in  real  time  and  shall  be  knowledgeable  of  their  OIPT  leader’s 
assessment.  OIPT  and  other  staff  members  shall  not  require  the  PM  to  provide  pre-briefs 
independent  of  the  OIPT  process. 

C7.6.5.  WIPT  Procedures,  Roles,  and  Responsibilities 

C7.6.5.1.  The  PM,  or  designee,  shall  form  and  lead  an  IIPT  to  support  the  development 
of  strategies  for  acquisition  and  contracts,  cost  estimates,  evaluation  of  alternatives,  logistics 
management,  training,  cost-performance  trade-offs,  etc.  The  PM,  assisted  by  the  IIPT,  shall 
develop  and  propose  to  the  OIPT,  a  WIPT  structure.  The  IIPT  shall  coordinate  the  activities  of 
the  WIPTs  and  review  issues  they  do  not  address.  WIPTs  shall  meet  as  required  to  help  the  PM 
plan  program  structure  and  documentation  and  resolve  issues.  While  there  is  no  one-size-fits-all 
WIPT  approach,  the  following  basic  tenets  shall  apply: 

C7.6.5.1.1.  The  PM  is  in  charge  of  the  program. 

C7.6.5.1.2.  IPTs  are  advisory  bodies  to  the  PM. 

C7.6.5. 1 .3.  Direct  communication  between  the  program  office  and  all  levels  in  the 
acquisition  oversight  and  review  process  is  expected  as  a  means  of  exchanging  information  and 
building  trust. 

C7. 6.5.2.  The  PM  or  PM’s  representative  shall  normally  lead  each  IPT.  At  the 
invitation  of  the  PM,  an  OSD  action  officer  may  co-chair  IPT  meetings.  The  following  roles  and 
responsibilities  shall  apply  to  all  WIPTs: 

C7. 6.5.2. 1.  Assist  the  PM  in  developing  strategies  and  in  program  planning,  as 
requested  by  the  PM. 

C7.6.5.2.2.  Establish  an  IPT  plan  of  action  and  milestones. 

C7.6.5.2.3.  Propose  tailored  documentation  and  milestone  requirements. 

C7.6.5.2.4.  Review  and  provide  early  input  to  documents. 

C7.6.5.2.5.  Coordinate  WIPT  activities  with  the  OIPT  members. 
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Cl. 6.52.6.  Resolve  or  elevate  issues  in  a  timely  manner. 

C7.6.5.2.7.  Assume  responsibility  to  obtain  principals’  concurrences  on  issues, 
documents,  or  portions  of  dociunents. 

C7.6.5.3.  IPTs  are  critical  to  program  success,  and  training  is  critical  to  IPX  success. 

All  WIPT  members  for  ACAT  ID  and  ACAT  lAM  programs  shall  receive  formal,  team-specific 
training  and,  as  necessary,  general  IPX  procedural  training. 

C7.6.6.  Cost/Performance  IPX 

C7.6.6.1.  ACAX  ID  and  ACAX  lAM  (as  required)  programs  shall  establish  a 
CostX*erformance  IPX.  Xhe  team  shall  include  representatives  of  the  user,  costing,  analysis,  and 
budgeting  communities,  at  minimum,  and  include  other  members  as  and  when  appropriate, 
including  industry  or  contractors,  consistent  with  statute  and  the  policy  in  paragraph  C7.6.3. 
Normally,  the  PM  or  the  PM’s  representative  shall  lead  the  Cost/Performance  IPX. 

C7.6.6.2.  Xhe  PM,  supported  by  the  Cost/Performance  IPX,  shall  conduct  and  integrate 
all  program  cost  and  performance  trade-off  analyses.  Xhe  empowered  Cost/Performance  IPX 
may  effect  performance  or  engineering  and  design  changes  provided  they  do  not  violate 
threshold  values  in  the  ORD  and  APB.  If  the  changes  require  ORD  or  APB  threshold  value 
changes,  the  PM  shall  notify  the  OIPX  leader.  Xhe  PM  shall  quickly  bring  proposed  changes 
before  the  ORD  and/or  APB  approval  authorities  for  decision.  Prior  to  each  major  decision 
point,  the  PM  shall  report  the  Cost/Performance  IPX  cost  and  performance  findings  to  the  OIPX 
leader  and  brief  their  relationship  to  the  program  baseline. 

Cl. 6.1.  Independent  Assessments.  Assessments,  independent  of  the  developer  and  the  user, 
ensure  an  impartial  evaluation  of  program  status.  Consistent  with  statutory  requirements  and 
good  management  practice,  the  Department  of  Defense  shall  require  independent  assessments  of 
program  status  (e.g.,  the  independent  cost  estimate  or  technology  readiness  assessment).  Senior 
acquisition  officials  shall  consider  these  assessments  when  making  acquisition  decisions.  Staff 
offices  that  provide  independent  assessments  shall  support  the  orderly  and  timely  progression  of 
programs  through  the  acquisition  process.  IPXs  shall  have  access  to  independent  assessments  to 
enable  full  and  open  discussion  of  issues. 

C7.6.8.  Component  Programs.  Xhe  decision  review  processes  discussed  in  this  section  deal 
specifically  with  ACAX  ID  and  ACAX  LAM  programs.  CAEs  shall  develop  similar  tailored 
procedures  for  programs  under  their  cognizance. 
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C7.7.  PROGRAM  INFORMATION 

C7.7.1 .  It  shall  be  Department  policy  to  keep  reporting  requirements  to  a  minimum. 
Nevertheless,  complete  and  current  program  information  is  essential  to  the  acquisition  process. 
Consistent  with  the  tables  of  required  regulatory  and  statutory  information  appearing  in  DoD 
Instruction  5000.2  (reference  (a)),  decision  authorities  shall  require  PMs  and  other  participants  in 
the  defense  acquisition  process  to  present  only  the  minimum  information  necessary  to  understand 
program  status  and  make  informed  decisions.  The  MDA  shall  “tailor-in”  program  information 
case-by-case,  as  necessary.  IPTs  shall  facilitate  the  management  and  exchange  of  program 
information. 

Cl. 1.2.  The  PM,  DoD  Component,  or  OSD  staff  prepares  most  program  information.  Some 
information  requires  approval  by  an  acquisition  executive.  Other  information  is  for 
consideration  only.  In  most  cases,  information  content  and  availability  is  more  important  than 
format.  This  Regulation  clearly  identifies  the  few  mandatory  document  formats. 

Cl. 1.3.  PMs  may  submit  mandatory  information  as  stand-alone  documents  or  as  a  single 
document.  If  the  PM  submits  stand-alone  documents,  the  PM  shall  not  redundantly  include  the 
same  information  in  each  document. 

C7.8.  LIFE-CYCLE  MANAGEMENT  OF  INFORMATION 

PMs  shall  comply  with  record  keeping  responsibilities  under  the  Federal  Records  Act  for  the 
information  collected  and  retained  in  the  form  of  electronic  records  (see  DoD  Directive  5015.2 
(reference  (fffff))).  Electronic  record  keeping  systems  shall  preserve  the  information  submitted, 
as  required  by  Title  44  (reference  (ggggg))  and  implementing  regulations.  Electronic  record 
keeping  systems  shall  also  provide,  wherever  appropriate,  for  the  electronic  acknowledgment  of 
electronic  filings  that  are  successfully  submitted.  PMs  shall  consider  the  record  keeping 
functionality  of  any  systems  that  store  electronic  documents  and  electronic  signatures  to  ensure 
users  have  appropriate  access  to  the  information  and  can  meet  the  agency’s  record  keeping 
needs. 

C7.9.  JOINT  REQUIREMENTS  OVERSIGHT  COUNCIL  UROC) 

C7.9.1.  The  JROC  shall  review  all  deficiencies  that  may  necessitate  development  of  major 
systems  prior  to  any  consideration  by  the  DAB  or,  as  appropriate,  the  DoD  CIO.  The  JROC 
shall  validate  the  identified  mission  need,  recommend  a  joint  potential  desi^ator  for  meeting  the 
need  (CJCS  Instruction  3170.01B  (reference  (f))),  and  forward  the  MNS,  with  JROC 
recommendations,  to  the  USD(AT&L)  or  ASD(C3I),  as  appropriate.  The  JROC  shall  play  a 
continuing  role  in  the  validation  of  KPPs. 
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Cl. 9.2.  In  accordance  with  10  U.S.C.  181  (reference  (i)),  the  JROC  shall  assist  the 
Chairman  of  the  Joint  Chiefs  of  Staff  in  the  following  ways: 

C7.9.2. 1 .  Identify  and  assess  the  priority  of  joint  military  requirements  (including 
existing  systems  and  equipment)  to  meet  the  national  military  strategy; 

C7. 9.2.2.  Consider  alternatives  to  any  acquisition  program  that  has  been  identified  to 
meet  military  requirements  by  evaluating  the  cost,  schedule,  and  performance  criteria  of  the 
program  and  of  the  identified  alternatives;  and 

C7.9.2.3.  Ensure  that  the  assignment  of  the  priorities  of  joint  military  requirements 
conforms  to  and  reflects  resource  levels  projected  by  the  Secretary  of  Defense  through  defense 
planning  guidance. 

C7.9.3.  The  JROC  shall  be  the  initiation  authority  for  CRDs.  A  CRD  captures  the 
overarching  requirements  for  a  mission  area,  forming  a  family-of-systems  (e.g.,  space  control, 
theater  missile  defense,  etc.)  or  system-of-systems  (e.g.,  national  missile  defense).  CRDs,  when 
required,  shall  guide  the  DoD  Components  in  developing  ORDs  for  future  systems  and 
upgrading  existing  systems  (CJCS  Instruction  3170.01B  (reference  (f))). 

C7.10.  JOINT  PROGRAM  MANAGEMENT 

A  joint  program  is  any  acquisition  system,  subsystem,  component,  or  technology  program  with 
an  acquisition  strategy  that  includes  funding  by  more  than  one  DoD  Component  during  any 
phase  of  a  system's  life  cycle. 

C7.10.1.  Designation 

C7. 10. 1.1.  The  Requirements  Authority  shall  review  and  validate  ACAT I  or  ACAT  lA 
MNSs  and  ORDs.  They  shall  recommend  forming  joint  programs  based  on  joint  potential,  and 
recommend  assignment  of  lead  executive  component  to  USD(AT&L)/ASD(C3I).  DoD 
Component  Heads  shall  also  recommend  forming  joint  programs,  as  appropriate.  The  MDA 
shall  make  the  decision  to  establish  a  joint  program,  and  designate  the  lead  executive  component, 
as  early  as  possible  in  the  acquisition  process. 

C7. 10.1.2.  The  DoD  Components  shall  periodically  review  their  programs  and 
requirements  to  determine  the  potential  for  cooperation.  They  shall  structure  mission  needs, 
operational  requirements,  and  program  strategies  to  encourage  and  to  provide  an  opportunity  for 
multi-Component  participation. 

C7.10.1.3.  Joint  programs  shall  include  programs  with  a  designated  acquisition  agent, 
considered  the  lead  component,  acting  on  behalf  of  one  or  more  components,  regardless  of  the 
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source  of  the  designation  (i.e.,  mutual  agreement,  statute,  DoD  Directive,  or  USD(AT&L)  or 
ASD(C3I))  decision. 

C7. 10.2.  Memorandum  of  Agreement.  A  Memorandum  of  Agreement  shall  specify  the 
relationship  and  respective  responsibilities  of  the  lead  executive  component  and  the  other 
participating  components.  The  Memorandum  of  Agreement  shall  address,  at  minimum,  the 
following  topics:  system  requirements,  funding,  manpower,  and  the  approval  process  for  the 
ORD  and  other  program  documentation. 

C7.10.3.  Procedures.  The  following  guidance  applies  to  joint  programs: 

C7. 10.3.1.  The  USD(AT&L)/ASD(C3I),  with  the  advice  and  counsel  of  the  military 
services  and  the  JROC,  shall  make  the  decision  to  assign  a  lead  executive  component  for  a  joint 
program.  The  assignment  of  a  lead  executive  component  shall  consider  the  following: 

C7. 10.3. 1.1.  Demonstrated  best  business  practices  including  a  plan  for  effective, 
economical  and  efficient  management  of  the  joint  program;  and 

C7. 10.3. 1.2.  Demonstrated  DoD  Component  willingness  to  fund  the  core  program, 
essential  to  meet  joint  program  needs. 

Cl.  10.3.2.  The  MDA  shall  consolidate  and  co-locate  joint  programs  at  the  lead 
executive  component's  program  office,  to  the  maximum  extent  practicable. 

C7. 10.3.3.  The  CAE  of  a  designated  acquisition  agent  given  acquisition  responsibilities 
shall  utilize  the  acquisition  and  test  organizations  and  facilities  of  the  military  departments  to  the 
maximum  extent  practicable. 

C7. 10.3.4.  The  designated  lead  executive  component  shall  select  a  single  qualified  PM 
for  the  designated  joint  program.  The  selected  joint  PM  is  fully  responsible  and  accountable  for 
the  cost,  schedule,  and  performance  of  the  development  system. 

C7.10.3.5.  If  the  joint  program  is  a  consolidation  of  several  programs  with  multiple 
Component  PMs,  the  joint  PM  retains  responsibility  for  overall  system  development  and 
integration. 

C7. 10.3.6.  A  designated  joint  program  shall  have  one  quality  assurance  program,  one 
program  change  control  program,  one  integrated  test  program,  and  one  set  of  documentation  and 
reports  (specifically:  one  joint  program  ORD,  one  C4ISP,  one  TEMP,  one  APB,  etc.). 

C7. 10.3.7.  Documentation  for  decision  points  and  periodic  reports  shall  flow  only 
through  the  lead  executive  component  acquisition  chain,  supported  by  the  participating 
components. 
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C7. 10.3.8.  The  program  shall  use  inter-Component  logistics  support  to  the  maximxun 
extent  practicable,  consistent  with  effective  support  to  the  operational  forces  and  efficient  use  of 
DoD  resources. 

C7. 10.3.9.  The  MDA  shall  designate  a  lead  OTA  to  coordinate  all  operational  test  and 
evaluation.  The  lead  OTA  shall  produce  a  single  operational  effectiveness  and  suitability  report 
for  the  program. 

C7.10.3.10.  Unless  statute,  the  MDA,  or  a  memorandum  of  agreement  signed  by  all 
components  directs  otherwise,  the  lead  executive  component  shall  budget  for  and  manage  the 
common  RDT&E  fimds  for  assigned  joint  programs. 

C7. 10.3.1 1.  Individual  components  shall  budget  for  their  unique  requirements. 

C7. 10.3. 12.  The  DoD  Components  shall  not  terminate  or  substantially  reduce 
participation  in  joint  ACAT  ID  programs  without  Requirements  Authority  review  and 
USD(AT&L)  approval;  or  in  joint  ACAT  lA  programs  without  Requirements  Authority  review 
and  ASD(C3I)  approval.  The  USD(AT&L)  or  ASD(C3I)  may  require  a  component  to  continue 
some  or  all  funding,  as  necessary,  to  sustain  the  joint  program  in  an  efficient  manner,  despite 
approving  their  request  to  terminate  or  reduce  participation.  Substantial  reduction  is  defined  as  a 
funding  or  quantity  decrease  of  50%  or  more  in  the  total  funding  or  quantities  in  the  latest 
President's  Budget  for  that  portion  of  the  joint  program  funded  by  the  component  seeking  the 
termination  or  reduced  participation. 

C7. 1 1  ■  INTERNATIONAL  COOPERATIVE  PROGRAM  MANAGEMENT 

An  international  cooperative  program  is  any  acquisition  system,  subsystem,  component,  or 
technology  program  with  an  acquisition  strategy  that  includes  participation  by  one  or  more 
foreign  nations,  through  an  international  agreement,  during  any  phase  of  a  system's  life  cycle. 

All  international  cooperative  programs  shall  fully  comply  with  program  protection  requirements. 
Programs  containing  classified  information  shall  have  a  Delegation  of  Disclosure  Authority 
Letter  prior  to  entering  discussions  with  potential  foreign  partners. 

C7. 11.1.  Designation.  MDAs  shall  recommend  forming  international  cooperative  programs 
based  on  the  international  program  acquisition  strategy  considerations  addressed  in  paragraph 
C2.9.2.  The  Heads  of  the  DoD  Components  shall  also  recommend  forming  international 
cooperative  programs,  as  appropriate.  The  MDA  shall  make  a  decision  to  attempt  to  establish  an 
international  cooperative  program  as  early  as  possible  in  the  acquisition  process.  The  DoD 
Components  shall  periodically  review  their  programs  to  determine  the  potential  for  international 
cooperation. 
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Cl.  1 1 .2.  International  Agreement.  The  cooperative  program  international  agreement  shall, 
in  accordance  with  DoD  Directive  5530.3  (reference  (hhhhh)),  specify  the  relationship  and 
respective  responsibilities  of  the  Department  of  Defense  and  the  participating  nation(s). 

C7.11.3.  Procedures.  The  following  guidance  applies  to  international  cooperative 
programs: 

C7. 1 1 .3. 1 .  The  USD(AT&L)/ASD(C3I)  or  the  applicable  DoD  Component,  with  the 
advice  and  counsel  of  the  military  services  and  the  JROC,  shall  make  the  decision  to  pursue  an 
international  cooperative  program.  The  decision  process  shall  consider  the  following: 

C7. 1 1 .3 . 1 . 1 .  Demonstrated  best  business  practices  including  a  plan  for  effective, 
economical  and  efficient  management  of  the  international  cooperative  program;  and 

C7.1 1.3.I.2.  Demonstrated  DoD  Component  willingness  to  fully  fund  their  share 
of  international  cooperative  program  needs. 

C7.1 1.3.I.3.  The  long-term  interoperability  and  political-military  benefits  that  may 
accrue  from  international  cooperation. 

C7.1 1.3.2.  The  DoD  Component  shall  agree  upon  the  international  program’s 
management  structure  and  document  this  in  the  international  agreement.  The  designated  PM 
(U.S,  or  foreign)  is  fully  responsible  and  accountable  for  the  cost,  schedule,  and  performance  of 
the  development  system. 

C7.1 1.3.3.  The  DoD  Component  shall  remain  responsible  for  preparation  and  approval 
of  DoD-required  documentation  and  reports  (specifically:  ORD,  C4ISP,  TEMP,  APB, 

Delegation  of  Disclosure  Authority  Letter,  etc.). 

Cl.  1 1.3.4.  Documentation  for  decision  points  and  periodic  reports  shall  flow  through 
the  DoD  Component  acquisition  chain,  supported  by  the  participating  nation(s),  as  required. 

Cl.  1 1.3.5.  The  DoD  Components  shall  not  terminate  or  substantially  reduce 
participation  in  international  cooperative  ACAT  ID  programs  under  signed  international 
agreements  without  USD(AT&L)  approval;  or  in  international  cooperative  ACAT  lAM 
programs  without  ASD(C3I)  approval.  A  DoD  Component  may  not  termmate  or  substantially 
reduce  U.S.  participation  in  an  international  cooperative  program  until  after  providing 
notification  to  the  USD(AT&L)  or  ASD(C3I).  As  a  result  of  that  notification,  the  USD(AT&L) 
or  the  ASD(C3I)  may  require  the  DoD  Component  to  continue  to  provide  some  or  all  of  the 
funding  for  that  program  in  order  to  minimize  the  impact  on  the  international  cooperative 
program.  Substantial  reduction  is  defined  as  a  funding  or  quantity  decrease  of  25%  or  more  in 
the  total  funding  or  quantities  in  the  latest  President's  Budget  for  that  portion  of  the  international 
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cooperative  program  funded  by  the  DoD  Component  seeking  the  termination  or  reduced 
participation. 

C7.12.  COST  ANALYSIS  IMPROVEMENT  GROUP  fCAIGi  PROCEDURES 

C7.12.1.  Responding  to  10  U.S.C.  2434  (reference  (sss)),  DoD  Directive  5000.4  (reference 
(iiiii))  charters  the  OSD  CAIG  to  provide  independent  program  cost  estimates.  The  DoD 
Component  responsible  for  acquisition  of  a  system  shall  cooperate  with  the  CAIG  and  provide 
the  cost,  programmatic,  and  technical  information  required  to  estimate  costs  and  appraise  cost 
risks.  The  DoD  Component  shall  also  facilitate  CAIG  staff  visits  to  the  program  office,  product 
centers,  test  centers,  and  system  contractoifs). 

C7.12.2.  The  following  guidance  shall  apply  to  AC  AT  ID  programs  (and  AC  AT  IC,  as 
requested  by  the  USD(AT&L))  preparing  for  a  Milestone  B  or  C  review;  the  decision  review 
prior  to  entering  full-rate  production  and  deployment;  or  any  other  decision  point  as  directed  by 
the  USD(AT&L): 

C7. 12.2.1.  The  PM  and  DoD  Component  shall  provide  draft  life-cycle  cost  estimates  to 
the  CAIG  at  least  45  calendar  days  before  the  scheduled  OIPT  or,  as  applicable,  the  component 
review  meeting. 

C7. 12.2.2.  The  PM  and  component  shall  provide  life-cycle  cost  estimates  and/or 
component  cost  positions  to  the  OSD  CAIG  at  least  21  calendar  days  before  the  scheduled  OIPT 
or  component  review  meeting.  The  CAIG  shall  provide  feedback  based  on  independent  review 
of  the  life-cycle  cost  estimate(s),  validating  the  methodology  used  to  estimate  costs  and 
determining  whether  the  estimate(s)  require  additional  analysis. 

C7. 12.2.3.  The  PM  and  component  shall  provide  final  life-cycle  cost  estimates  and/or 
component  cost  positions  to  the  OSD  CAIG  at  least  10  calendar  days  before  the  scheduled  OIPT 
or  component  review  meeting. 

C7.13.  CONTRACTOR  COUNCILS 


C7.13.1.  DCMA  shall  support  the  formation  of  management,  sector,  and/or  corporate 
councils  by  each  prime  contractor  under  DCMA  cognizance  supporting  ACAT  I,  ACAT  lA,  or 
ACAT II  programs.  These  councils  provide  an  interface  with  the  Contract  Management  Office 
Commander;  the  Defense  Contract  Audit  Agency  Resident  Auditor;  representatives  from  all 
affected  acquisition  management  activities  (including  PMs,  Item  Managers,  and  Single  Process 
Initiative  Component  Team  Leaders),  or  designated  representatives  for  any  of  the  above  listed 


Not  applicable  to  ACAT  lA  programs. 
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individuals.  Acquisition  managers  or  designees  shall  support  both  council  activities  and  council- 
sponsored  IPTs.  Acquisition  managers  shall  assist  the  councils  to  keep  all  the  stakeholders 
informed  about  issues  affecting  multiple  acquisition  programs,  to  work  issues  quickly,  and  to 
elevate  unresolved  issues  to  appropriate  levels  for  resolution.  These  councils  may  identify  and 
propose  acquisition  process  streamlining  improvements.  Acquisition  managers  shall  assist  and 
encourage  councils  to  coordinate  and  integrate  program  audit  and  review  activity,  support  and 
promote  civil-military  integration  initiatives,  and  accept  contractor  Single  Process  Initiative 
proposals  and  other  ideas  that  reduce  TOC  while  meeting  performance  based  specifications. 

C7.13.2.  Program  office  staff  shall  interface  with  contractors'  councils,  keeping  in  mind  that 
such  councils  are  not  Federal  Advisory  Committees  under  FACA  (reference  (cc)).  The  staff  may 
find  that  these  councils  strengthen  the  corporate  relationship  with  DoD,  provide  an  interface 
between  company  representatives  and  acquisition  managers,  communicate  acquisition  reform 
initiatives^  or  even  resolve  issues.  In  leading  corporate  endeavors  such  as  Single  Process 
Initiative  proposals,  civil-military  integration  ideas,  or  other  initiatives  designed  to  achieve 
efficiencies  for  the  company,  these  councils  may  ultimately  produce  savings  for  the  government. 

C7.14.  MANAGEMENT  CONTROL 

C7.14.1.  PMs  shall  implement  internal  management  controls  in  accordance  with  DoD 
Directive  5000.1  (reference  (jjjjj)),  DoD  Instruction  5000.2  (reference  (a)),  this  Regulation,  and 
DoD  Directive  5010.38  (reference  (kkkkk)).  APB  parameters  shall  serve  as  control  objectives. 
PMs  shall  identify  deviations  from  approved  APB  parameters  and  exit  criteria  as  materiel 
weaknesses.  PMs  shall  focus  on  results,  not  process. 

C7.14.2.  PMs  shall  ensure  that  obligations  and  costs  comply  with  applicable  law.  They 
shall  safeguard  assets  against  waste,  loss,  unauthorized  use,  and  misappropriation;  properly 
record  and  account  for  expenditures;  maintain  accountability  over  assets;  and  quickly  correct 
identified  weaknesses. 

C7.15.  PERIODIC  REPORTING 

Periodic  reports  shall  include  only  those  reports  required  by  the  MDA  or  statute.  Except  for  the 
reports  outlined  in  this  section,  the  MDA  shall  tailor  the  scope  and  formality  of  reporting 
requirements. 

C7.15.1.  Program  Plans 

C7.15.1.1.  Program  plans  describe  the  detailed  activities  of  the  acquisition  program.  In 
coordination  with  the  PEG,  the  PM  shall  determine  the  type  and  number  of  program  plans 
needed  to  manage  program  execution. 
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C7. 15.1.2.  Decision  authorities  shall  not  require  approval  of  program  plans,  except  by 
the  PM,  for  other  than  the  TEMP  and  C4ISP.  Program  plans  shall  not  serve  as  decision  point 
documentation  or  periodic  reports. 

C7.15.2.  APB  Reporting.  PMs  shall  report  the  current  estimate  (see  subparagraph 
Cl. 4.5.1.)  of  each  APB  parameter  periodically  to  the  MDA.  The  MDA  shall  direct  the  frequency 
of  the  reporting.  PMs  shall  report  current  estimates  for  ACAT I  and  LA  programs  quarterly  in  the 
DABS. 

C7.15.3.  DAES  -  DD  ACQ(Q)1429 

C7. 15.3.1.  The  DAES  is  a  multi-part  document,  reporting  program  information  and 
assessments;  PM,  PEO,  CAE  comments;  and  cost  and  funding  data.  The  DAES  shall  be  an 
early-warning  report  to  USD(AT&L)  and  ASD(C3I).  The  DAES  describes  actual  program 
problems,  warns  of  potential  program  problems,  and  describes  mitigating  actions  taken.  The  PM 
may  obtain  permission  from  USD(AT&L)  or  ASD(C3I),  as  appropriate,  to  tailor  DAES  content. 
At  minimum,  the  DAES  shall  report  program  assessments  (including  interoperability),  unit  costs 
(10  U.S.C.  2433  (reference  (11111))),  and  current  estimates.  It  shall  report  the  status  of  exit  criteria 
and  vulnerability  assessments  (FMFIA  (reference  (mmmmm))). 

C7. 15.3.2.  The  DAES  shall  present  total  costs  and  quantities  for  all  years,  as  projected, 
through  the  end  of  the  current  acquisition  phase.  In  keeping  with  the  concept  of  total  program 
reporting,  the  DAES  shall  present  best  estimates  for  costs  beyond  the  FYDP,  if  the  FYDP  does 
not  otherwise  identify  those  costs.  The  total  program  concept  refers  to  system  acquisition 
activities  from  Concept  and  Technology  Development  through  Production  and  Deployment.  The 
DAES  shall  report  approved  program  funding  for  programs  that  are  subsystems  to  platforms  and 
whose  procurement  is  reported  in  the  platform  budget  line. 

C7.15.3.3.  The  Office  of  USD(AT&L) ,  the  Office  of  ASD(C3I),  the  Offices  of  DoD 
CAEs,  CIOs,  and  PEOs,  and  the  program  office  shall  each  establish  DAES  focal  points. 

C7. 15.3.4.  DAES  Reporting.  USD(AT&L)  shall  designate  ACAT  I  programs  subject 
to  DAES  reporting  and  assign  each  program  to  a  quarterly  reporting  group.  ASD(C3I)  shall 
designate  ACAT  LA  programs  subject  to  DAES  reporting  and  assign  each  program  to  a  quarterly 
reporting  group.  The  PM  shall  use  the  CARS  (see  Appendix  1)  to  prepare  the  DAES,  and  submit 
both  hard  and  electronie  copies  to  USD(AT&L)  by  the  last  working  day  of  the  program's 
designated  quarterly  reporting  month.  ACAT  lA  programs  shall  submit  an  electronic  copy  of 
their  DAES  report  to  ASD(C3I)  30  days  after  the  end  of  the  quarter.  The  PM  shall  not  delay  the 
DAES  for  any  reason. 
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C7. 15.3.5.  Out-of-Cycle  DAES.  There  are  two  types  of  out-of-cycle  DAES; 

C7.15.3.5.1.  The  PM  shall  submit  a  DAES  when  there  is  reasonable  cause  to 
believe  that  a  Nunn—McCurdy  imit  cost  breach  has  occurred  or  will  occur  (10  U.S.C.  2433(c) 
(reference  (11111))).  (Submitting  DAES  sections  5,  6.2,  and  7,  block  #28,  satisfies  this 
requirement.) 


C7.15.3.5.2.  If  submission  of  the  DoD  Component’s  POM  or  BES  causes  the 
program  to  deviate  fi'om  the  approved  APB  thresholds,  the  PM  shall  submit  DAES  sections  5., 
6.2,  and  8. 

C7.15.3.6.  Consistency  of  DAES  Information.  DAES  information  shall  be  consistent 
with  that  in  the  latest  ADM,  APB,  and  other  mandatory  or  approved  program  documentation. 

C7.15.4.  Selected  Acquisition  Report  (SAR)  DD-COMP  (Q&A)  823*^ 

C7.15.4.1.  In  accordance  with  10  U.S.C.  2432  (reference  (nnnnn)),  the  PM  shall  submit 
a  SAR  to  Congress  for  all  ACAT  I  programs.  The  PM  shall  use  CARS  software  to  prepare  the 
SAR. 


C7. 15.4.2.  SAR  Content  and  Submission 

C7. 15.4.2.1.  The  SAR  shall  report  the  status  of  total  program  cost,  schedule,  and 
performance;  as  well  as  program  unit  cost  and  unit  cost  breach  information.  For  joint  programs, 
the  SAR  shall  report  the  information  by  participant.  Each  SAR  shall  include  a  fiill,  life-cycle 
cost  analysis  for  the  reporting  program,  each  of  its  evolutionary  blocks,  as  available,  and  for  its 
antecedent  program,  if  applicable. 

C7. 15.4.2.2.  The  SAR  for  the  quarter  ending  December  31  shall  be  called  the 
annual  SAR.  The  PM  shall  submit  the  annual  SAR  within  60  days  after  the  President  transmits 
the  following  fiscal  year's  budget  to  Congress.  Annual  SARs  shall  reflect  the  President's  Budget 
and  supporting  documentation.  The  annual  SAR  is  mandatory  for  all  programs  that  meet  SAR 
reporting  criteria. 

C7. 15.4.2.3.  The  PM  shall  submit  SARs  for  the  quarters  ending  March  31,  June 
30,  and  September  30  not  later  than  45  days  after  the  quarter  ends.  Quarterly  SARs  are  reported 
on  an  exception  basis,  as  follows: 


'  *  Not  applicable  to  ACAT  lA  programs. 
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C7. 15.4.2. 3.1.  The  current  estimate  (see  Cl.4.5.1.)  exceeds  the  Program 
Acquisition  Unit  Cost  (PAUC)  objective  or  the  Average  Procurement  Unit  Cost  (APUC) 
objective  of  the  currently  approved  APB,  both  in  base-year  dollars,  by  15  percent  or  more; 

C7. 15.4.2.3.2.  The  current  estimate  includes  a  6-month  or  greater  delay,  for 
any  schedule  parameter,  that  occurred  since  the  current  estimate  reported  in  the  previous  SAR; 

C7.15.4.2.3.3.  Milestone  B  or  Milestone  C  approval  occurs  within  the 
reportable  quarter. 

C7. 15.4.2.4.  Pre-Milestone  B  projects  may  submit  RDT&E-only  reports,  excluding 
procurement,  military  construction,  and  acquisition-related  operations  and  maintenance  costs. 
Components  shall  notify  USD(AT&L)  with  names  of  the  projects  for  which  they  intend  to 
submit  RDT&E-only  SARs  30  days  before  the  reporting  quarter  ends.  USD(AT&L)  shall  so 
notify  Congress  15  days  before  reports  are  due. 

C7.15.4.2.5.  Whenever  USD(AT&L)  proposes  changes  to  the  content  of  a  SAR,  he 
or  she  shall  submit  notice  of  the  proposed  changes  to  the  Armed  Services  Committees  of  the 
Senate  and  House  of  Representatives.  USD(AT&L)  may  consider  the  changes  approved,  and 
incorporate  them  into  the  report,  60  days  after  the  committees  receive  the  change  notice. 

C7. 15.4.3.  SAR  Waivers 

C7. 15.4.3.1.  The  Secretary  of  Defense  may  waive  the  requirement  for  submission 
of  SARs  for  a  program  for  a  fiscal  year  if: 

C7. 1 5.4.3 . 1 . 1 .  The  program  has  not  entered  system  development  and 

demonstration; 


C7.15.4.3.1.2.  A  reasonable  cost  estimate  has  not  been  established  for  the 

program;  and. 


C7. 15.4.3. 1.3.  The  system  configuration  for  the  program  is  not  well  defined. 

C7. 15.4.3.2.  As  delegated  by  the  Secretary  of  Defense,  USD(AT&L)  shall  submit 
a  written  notification  of  each  waiver  for  a  fiscal  year  to  the  Armed  Services  Committees  of  the 
Senate  and  House  of  Representatives  not  later  than  60  days  before  the  President  submits  the 
budget  to  Congress,  pursuant  to  31  U.S.C.  1105  (reference  (ooooo)),  in  that  fiscal  year. 

C7. 15.4.4.  SAR  Termination.  USD(AT&L)  shall  consider  terminating  SAR  reporting 
when  90  percent  of  expected  production  deliveries  or  planned  acquisition  expenditures  have  been 
made,  or  when  the  program  is  no  longer  considered  an  AC  AT  I  program  in  accordance  with  10 
U.S.C.  2430  (reference  (ppppp)). 
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C7.15.5.  Unit  Cost  Reports  (UCR)  COMP  (Q&AR)  159l‘^ 

C7. 15.5.1.  In  accordance  with  10  U.S.C.  2433  (reference  (11111)),  the  PM  shall  prepare 
UCRs  for  all  ACAT  I  programs  submitting  SARs,  except  pre-Milestone  B  programs  reporting 
RDT«&E  costs  only. 

C7.15.5.2.  Unit  Cost  Content  and  Submission.  The  PM  shall  submit  a  written  report  on 
the  unit  costs  of  the  program  to  the  CAE  on  a  quarterly  basis.  The  written  report  shall  be  in  the 
DAES.  The  PM  shall  submit  the  report  by  the  last  working  day  of  the  quarter,  in  accordance 
with  DAES  submission  procedures.  Reporting  shall  begin  with  submission  of  the  initial  SAR, 
and  terminate  with  submission  of  the  final  SAR.  Each  report  shall  include  the  current  estimate 
(see  subparagraph  Cl.4.5.1.)  of  the  PAUC  and  the  APUC  (in  base-year  dollars);  cost  and 
schedule  variances,  in  dollars,  for  each  of  the  major  contracts  since  entering  the  contract;  and  all 
changes  that  the  PM  knows  or  expects  to  occur  to  program  schedule  or  performance  parameters, 
as  compared  to  the  currently  approved  APB. 

C7.15.5.3.  UCR  Breaches 

C7.15.5.3.1.  The  PM  shall  submit  a  UCR  to  the  CAE  immediately,  whenever  the 
PM  has  reasonable  cause  to  believe  that  the  current  estimate  (see  subparagraph  Cl.4.5.1.)  of 
either  the  PAUC  or  APUC  (in  base-year  dollars)  increases  by  15%  or  more  over  the  PAUC 
objective  or  APUC  objective  of  the  currently  approved  APB  (in  base  year  dollars),  respectively. 
This  is  a  Congressionally  reportable  unit  cost  breach. 

C7.15.5.3.2.  If  the  CAE  determines  that  there  is  an  increase  in  the  current  estimate 
of  the  PAUC  or  APUC  cost  of  at  least  15%  or  more  over  the  currently  approved  APB,  the  CAE 
shall  inform  USD(AT&L)  and  the  cognizant  Head  of  the  DoD  Component.  If  the  cognizant  Head 
of  the  DoD  Component  subsequently  determines  that  there  is,  in  fact,  an  increase  in  the  current 
estimate  of  the  PAUC  or  APUC  of  at  least  15%  over  the  currently  approved  APB,  the  Head  of 
the  DoD  Component  shall  notify  Congress,  in  writing,  of  a  breach.  The  notification  shall  be  not 
later  than  45  days  after  the  end  of  the  quarter,  in  the  case  of  a  quarterly  report;  or  not  later  than 
45  days  after  the  date  of  the  report,  in  the  case  of  the  reasonable  cause  report.  In  either  case, 
notification  shall  include  the  date  that  the  Head  of  the  DoD  Component  made  the  determination. 

C7. 15.5.3.3.  In  addition,  the  Head  of  the  DoD  Component  shall  submit  a  SAR  for 
either  the  fiscal  year  quarter  ending  on  or  after  the  determination  date,  or  for  the  fiscal  year 
quarter  that  immediately  precedes  the  fiscal  year  quarter  ending  on  or  after  the  determination 
date.  This  SAR  shall  contain  the  additional,  breach-related  information. 


Not  applicable  to  ACAT  lA  programs. 
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C7.15.5.3.4.  If  the  current  estimate  of  the  PAUC  or  APUC  increases  by  at  least 
25%  over  the  PAUC  objective  or  APUC  objective  of  the  currently  approved  APB,  USD(AT&L) 
shall  submit  a  written  certification  to  Congress  before  the  end  of  the  30  day  period  beginning  on 
the  day  the  SAR  containing  the  unit  cost  information  is  required  to  be  submitted  to  Congress  (see 
subparagraph  C7. 15.4.2.).  The  certification  shall  state  the  following: 

C7. 15.5.3.4.1.  Such  acquisition  program  is  essential  to  the  national  security. 

C7.15.5.3.4.2.  There  are  no  alternative  programs  that  will  provide  equal  or 
greater  military  capability  at  less  cost. 

C7.15.5.3.4.3.  The  new  estimates  of  the  PAUC  or  APUC  are  reasonable. 

C7. 15.5.3. 4.4.  The  management  structure  for  the  acquisition  program  is 
adequate  to  manage  and  control  the  PAUC  and  the  APUC. 

C7. 15.5.3. 5.  If  the  Head  of  the  DoD  Component  makes  a  determination  of  either  a 
PAUC  or  APUC  15%  or  more  increase,  and  a  SAR  containing  the  additional  umt  cost  breach 
information  is  not  submitted  to  Congress  as  required;  or  if  the  Head  of  the  DoD  Component 
makes  a  determination  of  a  25%  increase  in  the  PAUC  or  APUC,  and  a  certification  of 
USD(AT&L)  is  not  submitted  to  Congress  as  required;  funds  appropriated  for  RDT&E, 
procurement,  or  mihtary  construction  may  not  be  obligated  for  a  major  contract  \mder  the 
program.  An  increase  in  the  PAUC  or  APUC  of  25%  or  more  resulting  from  the  termination  or 
cancellation  of  an  entire  program  shall  not  require  USD(AT&L)  program  certification. 

C7.15.6.  Program  Assessments 
C7. 15.6.1.  ACAT I  Programs 

C7.15.6.1.1.  The  Director,  Acquisition  Resources  and  Analysis  shall  determine,  at 
the  end  of  each  fiscal  year  and  for  each  program  separately,  if,  as  of  the  last  day  of  the  fiscal 
year,  more  than  10%  of  the  total  aggregate  number  of  cost,  schedule,  and  performance 
parameters  for  that  program  are  breached  against  the  APB  threshold  (10  U.S.C.  2220(b) 
(reference  (qqqqq)))-  If  more  than  10%  of  thresholds  are  breached,  for  ACAT  IC  programs  the 
appropriate  CAE  or  a  delegated  representative  (for  ACAT  IC  programs),  or  the  appropriate  OIPT 
Leader  or  a  delegated  representative  (for  ACAT  ID  programs),  shall  conduct  a  timely  review  of 
the  affected  program.  In  conducting  that  review,  the  CAE  or  the  OIPT  Leader,  together  with  the 
Vice  Chairman  of  the  Joint  Chiefs  of  Staff,  shall  determine  whether  there  is  a  continuing  need 
for  the  program,  and  shall  recommend  to  USD(AT&L)  suitable  actions  to  be  taken,  including 
termination,  with  respect  to  such  program  (10  U.S.C.  2220(c)  (reference  (rrrrr))). 
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C7.15. 6.1.2.  The  Director,  Acquisition  Resources  and  Analysis  shall  also  assess 
whether  the  average  period  for  converting  emerging  technology  to  operational  capability  has 
decreased  to  57.5  months  or  less  (i.e.,  50%  of  the  baseline  of  1 15  months  established  on  October 
13, 1994).  The  assessment  shall  be  based  on  data  provided  by  PMs  in  the  schedule  portion  of 
Section  5  of  the  DAES,  Approved  Program  Data,  which  will  allow  the  CARS  to  automatically 
calculate  the  total  time  in  number  of  months  between  program  initiation  and  IOC. 

C7.15. 6.1.3.  The  Director,  Acquisition  Resources  and  Analysis  shall  include  in  the 
Secretary  of  Defense  Annual  Report  to  the  President  and  to  Congress  the  names  of  the  programs 
that  have  breaches  of  more  than  ten  percent  and  the  assessment  of  average  time  if  that  average  is 
not  below  57.5  months  (10  U.S.C.  2222(b)  (reference  (sssss))). 

C7. 15.6.2.  ACAT  lA  Programs.  Based  on  the  data  provided  in  the  latest  DAES  report, 
the  Deputy  DoD  CIO  will  determine  whether  any  ACAT  lA  program,  or  any  phase  or  increment 
of  such  program,  has  significantly  deviated  fi'om  the  cost,  performance,  or  schedule  goals 
established  for  that  program.  If  the  Deputy  DoD  CIO  determines  that  a  significant  deviation  has 
occurred,  the  appropriate  DoD  Component  CIO  or  CAE,  and  for  ACAT  lAM  programs,  the  IT 
OIPT  Leader  or  designee,  shall  conduct  a  timely  review  of  the  affected  ACAT  LA  program.  In 
conducting  that  review,  the  DoD  Component  CIO  or  CAE  and  the  OIPT  Leader,  together  with 
the  cognizant  PSA,  shall  determine  whether  there  is  a  continuing  need  for  the  program  that  is 
sufficiently  behind  schedule,  over  budget,  or  not  in  compliance  with  performance  or  capability 
requirements,  and  shall  recommend  to  the  DoD  CIO  suitable  actions  to  be  taken,  including 
termination,  with  respect  to  such  program.  The  DoD  CIO  will  also  report  sigmficant  deviations 
of  ACAT  lA  programs  to  the  Office  of  Management  and  Budget  as  required  by  Section  5127  of 
the  Clinger-Cohen  Act  (40  U.S.C.  1427  (reference  (k))). 

C7.15.7.  Contract  Management  Reports.  Acquisition  participants  shall  use  the  reports 
prescribed  by  this  section  for  all  applicable  defense  contracts.  These  reports  ensure  effective 
defense  acquisition  management.  Participants  shall  use  electronic  media  unless  disclosure  of  this 
information  would  compromise  national  security.  The  WBS  used  to  prepare  these  reports  shall 
conform  to  the  program  WBS  (see  paragraph  C5.3.1.).  Except  for  high-cost  or  high-risk 
elements,  the  required  level  of  reporting  detail  shall  be  limited  to  level  three  of  the  contract 
WBS. 


C7. 1 5.7. 1 .  Contractor  Cost  Data  Reporting  (CCDR) 

C7.15.7.1.1.  CCDR  is  the  Department  of  Defense’s  primary  means  of  collecting 
data  on  the  costs  that  DoD  contractors  incur  in  performing  DoD  programs.  This  data  enables 


Not  applicable  to  ACAT  lA  programs. 
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reasonable  ACAT I  program  cost  estimates  and  satisfies  other  analytical  requirements.  The 
Chair,  CAIG,  shall  prescribe  a  format  for  submission  of  CCDRs.  The  Chair  shall  prescribe 
CCDR  system  policies  and  monitor  implementation  to  ensure  consistent  and  appropriate 
application  throughout  the  Department  of  Defense. 

C7. 15.7. 1.2.  CCDR  coverage  shall  extend  from  Milestone  B  or  equivalent  to  the 
completion  of  production  in  accordance  with  procedures  described  in  this  section.  Unless 
waived  by  the  Chair,  CAIG,  CCDR  reporting  is  required  on  all  major  contracts  and  subcontracts, 
regardless  of  contract  type,  for  ACAT  I  programs  valued  at  more  than  $42  million  (FY  2000 
constant  dollars).  CCDR  reporting  is  not  required  for  contracts  priced  below  $6.5  million.  The 
CCDR  requirement  on  high-risk  or  high-technical-interest  contracts  priced  between  $6.5  and  $42 
million  is  left  to  the  discretion  of  the  Cost  WIPT. 

C7. 15.7. 1 .3.  CCDR  reporting  shall  not  be  required  on  ship  development  and 
construction  contracts  because  of  their  unique  nature,  and  because  of  the  availability  of 
comparable  data  from  modified  Cost  Performance  Reports  (CPRs).  This  exclusion  does  not 
apply  to  contracts  for  shipboard  systems.  CCDR  reporting  shall  not  be  required  for  procurement 
of  commercial  systems,  or  for  non-commercial  systems  bought  imder  competitively  awarded, 
firm  fixed  price  contracts,  as  long  as  competitive  conditions  continue  to  exist. 

C7. 15.7. 1 .4.  For  ACAT  1  programs,  the  IPT  process  shall  develop  the  CCDR  plan 
and  forward  it  to  the  Chair,  CAIG,  for  approval.  CCDR  plan  approval  shall  occur  before  issuing 
industry  a  solicitation  for  integration  contracts.  The  CCDR  plan  reflects  the  proposed  collection 
of  cost  data,  by  WBS,  for  a  program.  The  plan  shall  describe  the  report  format  to  be  used  and 
shall  prescribe  reporting  frequency. 

C7. 15.7. 1.5.  A  cost-effective  reporting  system  requires  tailoring  the  CCDR  plan 
and  appropriately  defining  the  program  WBS.  Consistent  with  paragraph  C7.6.3.,  contractors 
may  participate  in  the  IPT  process. 

C7.15.7.1.6.  Each  DoD  Component  shall  designate,  by  title,  an  official  who  shall: 

C7.15.7.1.6.1.  Ensure  that  policies  and  procedures  are  established  for 
implementing  CCDR  in  accordance  with  this  section,  including  CCDR  data  storage  and 
distribution  to  appropriate  DoD  officials. 

C7.15.7.1.6.2.  Review  all  ACAT  I  program  CCDR  plans  and  CCDR  plan 
changes  for  compliance  with  CCDR  guidance  and  the  program  WBS,  and  forward  same  to  the 
CAIG. 


C7.15.7.1.6.3.  Advise  the  Chair,  CAIG,  annually  of  the  status  of  all  CCDR 
programs,  and  address  delinquent  or  deficient  CCDR  and  its  remedial  action. 
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C7. 15.7. 1.7.  The  CCDR  Project  Office  shall  annually  assess  the  need  for  field 
reviews  of  contractor  implementation  of  CCDR  for  ACAT  I.  Service  Cost  Centers  shall  assess 
the  need  for  field  reviews  of  less  than  ACAT  I  programs. 

C7. 15.7. 1.8.  The  following  general  policies  guide  the  preparation  of  the  CCDR 
Plan  for  all  ACAT  ID,  IC,  II,  and  III  programs.  In  general,  the  level  of  detail  and  frequency  of 
reporting  of  ACAT  II  and  III  programs  shall  normally  be  less  stringent  than  the  level  and 
firequency  applied  to  ACAT  I  programs  as  specified  below: 

C7. 15.7. 1.8.1.  Level  of  Cost  Reporting.  Routine  reporting  shall  be  at  the 
contract  WBS  level  three  for  prime  contractors  and  key  subcontractors.  Only  low-level  elements 
that  address  high  risk,  high  value,  or  high  technical  interest  areas  of  a  program  shall  require 
detailed  reporting  below  level  three.  The  Cost  WIPT  shall  identify  these  lower-level  elements 
early  in  CCDR  planning. 

C7.15.7.1.8.2.  Frequency.  The  Cost  WIPT  shall  define  CCDR  frequency  for 
development  and  production  contracts  to  meet  the  needs  of  the  program  for  cost  data  early  in 
CCDR  planning.  CCDRs  are  fundamentally  a  “returned”  (or  actual)  cost  reporting  system. 
Contractors  generally  do  not  need  to  file  cost  data  while  work  is  still  pending.  Thus,  for 
production  contracts,  contractors  shall  normally  submit  CCDR  reports  upon  the  delivery  of  each 
annual  lot.  For  developmental  contracts,  the  contractor  shall  typically  file  CCDR  reports  after 
major  events  such  as  first  flight  or  completion  of  prototype  lot  fabrication,  before  major 
milestones,  and  upon  contract  completion.  In  general,  quarterly  or  annual  reporting  requirements 
shall  not  meet  the  above  guidance. 

C7. 15.7.2.  Cost  Performance  Report  (CPR)  DID  DI-MGMT-8I466  (DoD  5010.12-L 
(reference  (ttttt))).  The  PM  shall  obtain  a  CPR  (DD  Form  2734/1, 2734/2, 2734/3, 2734/4,  and 
2734/5)  on  all  contracts  that  require  compliance  with  EVMS  guidelines  (see  subparagraph 
C2.9.3.4.  and  Appendix  4).  This  report  provides  contract  cost  and  schedule  performance  for 
program  management.  It  also  provides  early  indications  of  both  contract  cost  and  schedule 
problems  and  the  effect  of  implemented  management  actions  to  resolve  such  problems.  PMs 
shall  use  DID  DI-MGMT-81466  to  obtain  the  CPR.  The  following  guidance  applies: 

C7. 15.7.2.1.  Flexibly-priced  (e.g.,  fixed-price  incentive  or  cost  type)  contracts  that 
do  not  require  compliance  with  EVMS  guidelines,  but  for  which  the  DoD  Components  require 
more  data  than  is  available  on  the  C/SSR  (see  subparagraph  C7.15.7.3.)  may  require  CPRs.  CPR 
formats,  level  of  detail,  frequency,  and  variance  analysis  shall  be  limited  to  the  minimum 
necessary  for  effective  management  control. 

C7. 15.7.2.2.  FFP  contracts  shall  not  require  CPRs  xmless  unusual  circumstances 
dictate  cost  and  schedule  visibility. 
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C7. 15. 7.2.3.  Systems  used  for  internal  contractor  management  shall  summarize 
and  report  data  for  the  CPR. 

C7. 15.7.2.4.  The  PM  shall  tailor  the  CPR  to  the  minimum  required  data.  The 
contracting  officer  and  contractor  shall  negotiate  and  specify  all  reporting  provisions  in  the 
contract,  including  reporting  frequency,  variance  analysis  requirements,  and  the  contract  WBS  to 
report. 


C7. 15.7.2.5.  The  CPR  shall  be  a  primary  means  of  documenting  the  on-going 
communication  between  the  contractor  and  the  PM  to  report  cost  and  schedule  trends  to  date,  and 
to  permit  assessment  of  their  likely  effect  on  future  performance  on  the  contract. 

C7. 15.7.2.6.  CPRs  shall  be  provided  via  electronic  methods,  such  as  electronic 
access  to  contractors’  internal  data  bases,  or  via  Electronic  Data  Interchange  using  the  American 
National  Standards  Institute  Accredited  Standards  Committee  X12  transaction  set  for  Project 
Cost  Reporting  (839). 

C7. 15.7.3.  Cost/Schedule  Status  Report  (C/SSR)  DID  DI-MGMT-81467  (DoD 
5010.12-L  (reference  (ttttt))). 

C7.15.7.3.1.  The  PM  shall  obtain  a  C/SSR  (DD  Form  2735)  on  contracts  over  12 
months  in  duration,  when  the  CPR  does  not  apply.  The  C/SSR  provides  contract  cost  and 
schedule  performance  information  for  program  management.  The  C/SSR  has  no  specific 
application  thresholds;  however,  the  PM  shall  carefully  evaluate  application  to  contracts  of  less 
than  $6.3  million  (FY  2000  constant  dollars).  The  PM  shall  require  only  the  minimum 
information  necessary  for  effective  management  control.  FFP  contracts  shall  not  require  the 
C/SSR  unless  imusual  circumstances  dictate  cost  and  schedule  visibility.  PMs  shall  use  DID  DI- 
MGMT-81467  to  obtain  the  C/SSR. 

C7.15. 7.3.2.  C/SSRs  shall  be  provided  via  electronic  methods,  such  as  electronic 
access  to  contractors’  internal  databases,  or  via  Electronic  Data  Interchange  using  the  American 
National  Standards  Institute  Accredited  Standards  Committee  X12  transaction  set  for  Project 
Cost  Reporting  (839). 

C7. 15.7.4.  Contract  Fimds  Status  Report  (CFSR)  DI-MGMT-81468  (DoD  5010.12-L 
(reference  (ttttt))). 

C7.15.7.4.1.  The  PM  shall  obtain  a  CFSR  (DD  Form  1586)  on  contracts  over  6 
months  in  duration.  The  CFSR  provides  the  DoD  Components  with  information  to  update  and 
forecast  contract  funding  requirements;  to  plan  and  decide  on  funding  changes;  to  develop 
funding  requirements  and  budget  estimates  in  support  of  approved  programs;  and  to  detemune 
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funds  in  excess  of  contract  needs  and  available  to  be  deobligated.  PMs  shall  use  DID  DI- 
MGMT-81468  to  obtain  the  CFSR. 

C7. 15.7.4.2.  The  CFSR  has  no  specific  application  thresholds;  however,  the  PM 
shall  carefully  evaluate  application  to  contracts  of  less  than  $1.3  million  (FY  2000  constant 
dollars).  The  PM  shall  require  only  the  minimum  information  necessary  for  effective 
management  control.  FFP  contracts  shall  not  apply  the  CFSR  unless  unusual  circumstances 
dictate  specific  funding  visibility. 

C7. 15.7.4.3.  CFSRs  shall  be  provided  via  electronic  methods,  such  as  electronic 
access  to  contractors’  internal  databases,  or  via  Electronic  Data  Interchange  using  the  American 
National  Standards  Institute  Accredited  Standards  Committee  XI 2  transaction  set  for  Project 
Cost  Reporting  (839). 

C7.15.8.  Cooperative  Research  and  Development  Projects  Report.  USD(AT&L)  shall 
report  cooperative  research  and  development  projects  to  Congress  not  later  than  March  1  of  each 
year  (10  U.S.C.  2350a  (reference  (qq))X  The  report  shall  contain  descriptions  of  projects, 
funding,  schedules,  and  status  for  both  proposed  projects  and  projects  for  which  the  Memoranda 
of  Understanding  (or  other  formal  agreements)  have  been  entered  into  (10  U.S.C.  2350a(f) 
(reference  (uuuuu))). 
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API.  APPENDIX  1 

CONSOLIDATED  ACQUISITION  REPORTING  SYSTEM  (CARS) 
MANDATORY  PROCEDURES  AND  FORMATS 

APl.l.  CONSOLIDATED  ACQUISITION  REPORTING  SYSTEM  (CARS) 

API.I.l.  CARS  is  a  personal  computer-based  data  entry  and  reporting  software  package.  It 
maintains  and  reports  information  on  defense  programs.  The  use  of  CARS  is  mandatory  for  all 
MDAPs  and  MAIS  acquisition  programs,  but  non-MDAP  and  non-MAIS  programs  may  also  use 
the  system. 

API. 1.2.  CARS  has  three  reporting  modules  that  generate  the  APB,  the  SAR,  and  the 
DAES.  The  DAES  and  SAR  include  quarterly  unit  cost  and  unit  cost  breach  exception  reporting, 
respectively.  CARS  includes  analysis  routines,  such  as  the  Computational  Module  that  supports 
the  SAR  cost  change  calculations,  and  SAR  and  DAES  data  checks.  The  Director,  Acquisition 
Resources  and  Analysis,  maintains  a  CARS  help  line  for  user  support. 

API.  1.3.  A  unique  program  number  (PNO)  identification  system  controls  the  use  of  CARS. 
The  Office  of  USD(AT&L)  focal  point  assigns  a  PNO  to  each  using  ACAT I  program.  The 
Office  of  ASD(C3I)  focal  point  assigns  a  PNO  to  each  using  ACAT  lA  program. 

API. 1.4.  The  CARS  software  specifies  the  format  of  the  APB,  SAR,  and  DAES,  except  for 
narrative  or  memo  type  information. 

API. 1.5.  The  three  reporting  modules  share  some,  but  not  all,  of  the  CARS  data.  For 
example,  the  DAES  and  SAR  report  the  APB.  The  modules  also  share  some  contract 
information. 

API. 1.6.  Only  the  appropriate  Office  of  USD(AT&L)  or  DoD  Component  focal  point  can 
edit  some  of  the  CARS  information,  such  as  the  SAR  baseline  and  APB.  The  cognizant  MDA 
must  approve  SAR  baseline  and  APB  changes.  The  appropriate  Office  of  USD(AT&L)  or  DoD 
Component  focal  point  distributes  disks  containing  the  revised  or  new  information. 

API.  1.7.  The  Director,  Acquisition  Resources  and  Analysis,  has  responsibility  for  the 
development,  upgrade,  and  maintenance  of  CARS.  Direct  questions  and  requests  for  copies  of 
the  software  to  that  organization.  The  CARS  software  includes  mandatory  instructions  for 
preparing  the  APB,  SAR,  DAES,  and  UCR,  including  administrative  procedures.  The  CARS 
web  page,  http://www.acq.osd.mil/cars,  also  has  the  instructions.  The  automated  Defense 
Acquisition  Deskbook  contains  sample  formats  and  examples. 
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AP2.  APPENDIX  2 

TEST  AND  EVALUATION  MASTER  PLAN 
MANDATORY  PROCEDURES  AND  FORMAT 

AP2.1.  INTRODUCTION  AND  PURPOSE 

AP2.1.1.  This  Appendix  provides  procedures  and  formats  to  implement  the  requirements  of 
10  use  2399(b)(1),  "Operational  Test  and  Evaluation.”  The  TEMP  shall  document  the  overall 
structure  and  objectives  of  the  T&E  program.  It  shall  provide  the  framework  within  which  to 
generate  detailed  T&E  plans.  It  shall  document  schedule  and  resomce  implications  associated 
with  the  T&E  program.  The  TEMP  shall  identify  the  necessary  DT&E,  OT&E,  andLFT&E 
activities.  It  shall  relate  program  schedule,  test  management  strategy  and  structure,  and  required 
resources  to  COIs,  critical  technical  parameters,  KPPs  and  operational  performance  parameters 
(threshold  and  objective  criteria)  derived  from  the  ORD,  evaluation  criteria,  and  major  decision 
points. 

AP2.1.2.  The  TEMP  must  include  at  least  one  critical  technical  parameter  and  one 
operational  effectiveness  issue  for  the  evaluation  of  interoperability.  Both  the  TEMP  and 
operational  test  plans  should  also  specify  interoperability  test  concepts.  The  TEMPs  should 
reference  and  extract  performance  requirements  from  the  appropriate  CRDs,  ORDs,  C4ISPs,  and 
integrated  architectures.  The  Joint  Staff  will  ensure  that  all  CRDs,  and  ORDs  contain  specific, 
testable,  and  measurable  interoperability  requirements  and  KPPs.  USD(AT&L)  and 
ASD(C3I)/DoD  CIO  will  ensure  that  C4ISPs  and  integrated  architectures  reflect  the  appropriate 
family-of-systems  context  to  support  the  systems  interoperability  requirements.  The  OTAs,  the 
Joint  Staff,  and  the  system  user  or  program  proponent,  in  conjunction  with  Defense  Information 
Systems  Agency/JITC,  should  develop  the  test  procedures  and  effectiveness  measures  based  on 
the  requirements  and  expected  concepts  of  operations  for  the  systems.  The  OTAs  may  develop 
additional  issues  to  add  to  the  TEMP  and  test  plans  based  for  interoperability  and  interoperability 
test  and  evaluation. 

AP2.1.3.  Multi-service  or  joint  programs  shall  require  a  single  integrated  TEMP.  A  DoD 
Component-prepared  annex  to  the  basic  TEMP  may  address  DoD  Component-unique  content 
requirements,  particularly  evaluation  criteria  associated  with  COIs. 

AP2.1.4.  A  program  consisting  of  a  collection  of  individual  systems  shall  require  a  capstone 
TEMP.  The  capstone  TEMP  shall  integrate  the  T&E  program  for  the  entire  system.  An  annex  to 
the  basic  capstone  TEMP  shall  address  individual  system-imique  content  requirements.  The 
need  for  a  capstone  TEMP  depends  upon  the  degree  of  integration  and  interoperability  required 
to  satisfy  the  total  system's  interoperability  KPP,  associated  lERs,  and  other  appropriate 
operational  performance  parameters  (e.g.,  JTA  compliance). 
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AP2.2.  PREPARATION  AND  SUBMITTAL 

AP2.2.1.  The  T&E  WIPT  shall  develop  the  TEMP  for  ACAT I  programs,  selected  ACAT 
lAM  programs,  and  other  programs  on  the  OSD  T&E  Oversight  List  or  otherwise  vmder  DOT&E 
oversight  (collectively  termed  "OSD  T&E-oversight  programs").  The  TEMP  for  an  ACAT  I 
program  shall  be  submitted  to  the  Deputy  Director,  Developmental  Test  and  Evaluation,  in  the 
office  of  the  Director,  Strategic  and  Tactical  Systems,  for  OSD  approval,  30  days  prior  to 
Milestone  B  or  subsequent  program  initiation.  For  other  OSD  T&E-oversight  programs,  the 
TEMP  shall  be  submitted  within  90  days  of  such  designation. 

AP2.2.2.  Multi-Service  for  Joint  Programs.  The  lead  DoD  Component  shall  prepare  and 
coordinate  the  TEMP.  The  TEMP  signature  page  requires  approval  signatures  from  &e  lead 
component  and  all  participating  components. 

AP2.2.3.  Requirement  for  Other  DoD  Component  Coordination.  Where  a  program  of  any 
Component  must  interface  with  other  Components  during  development  and  testing  or  where  it 
will  interface  operationally  with  the  systems  of  other  Components,  coordination  of  the  affected 
Components  must  be  obtained  and  indicated  in  the  TEMP  before  it  is  submitted  to  USD(AT&L) 
DD,  DT&E/S&TS. 

AP2.2.4.  TEMP  Updates.  Update  the  TEMP  at  program  milestones  and  decision  reviews 
(see  section  C7.2.),  when  the  program  baseline  has  been  breached,  when  the  associated  ORD  or 
C4ISP  has  been  significantly  modified,  or  on  other  occasions  when  the  program  has  changed 
significantly.  Evolutionary  acquisition  programs  may  require  additional  updates  to  ensure  that 
the  TEMP  reflects  the  currently  defined  program.  When  a  baseline  breach  occurs,  the  TEMP 
will  be  updated  within  120  days  of  the  date  of  the  program  manager’s  Program  Deviation  Report. 
A\Tien  a  program  changes  significantly,  the  TEMP  due  date  will  be  negotiated  between  the 
program  manager  and  the  component  TEMP  approval  authority.  In  the  case  of  programs  under 
OSD  T&E  oversight,  the  negotiations  will  take  place  between  the  program  manager,  component 
TEMP  approval  authority,  DOT&E  and  DD,  DT&E/S&TS. 

AP2.2.5.  Review  and  Approval.  DOT&E  and  the  cognizant  OIPT  leader  shall  be  the  OSD 
TEMP  approval  authorities  for  ACAT  I  programs,  selected  ACAT  LAM  programs,  and  those 
other  acquisition  category  programs  designated  for  OSD  T&E  oversight.  The  possible  cognizant 
OIPT  leaders  are  the  Director  for  Strategic  and  Tactical  Systems;  the  Director,  Program  Analysis 
and  Integration;  and  the  Director,  Information  Technology,  Acquisition  and  Investment.  Formal 
submission  of  the  TEMP  for  OSD  approval  shall  be  accomplished  no  later  than  30  days  before 
the  Milestone  B  or  subsequent  program  initiation,  unless  otherwise  agreed  to  in  the  IPT.  Upon 
approval,  the  OSD  approval  Memorandxxm  becomes  part  of  the  TEMP,  and  shall  be  attached  to 
the  front  cover. 


136 


APPENDIX  2 


DoD  5000.2-R,  June  2001 


AP2.2.6.  Circumstances  when  a  TEMP  is  No  Longer  Required.  When  a  program's 
development  is  completed  and  COIs  are  satisfactorily  resolved,  including  the  verification  of 
deficiency  corrections,  TEMP  updates  are  no  longer  required.  The  following  attributes  are 
examples  for  which  an  updated  TEMP  submission  may  no  longer  be  required: 

AP2.2.6.1.  Fully  deployed  system  with  no  operationally  significant  product 
improvements  or  block  modification  efforts. 

AP2.2.6.2.  Full  production  ongoing  and  fielding  initiated  with  no  significant 
deficiencies  observed  in  production  qualification  test  results. 

AP2.2.6.3.  Partially  fielded  system  in  early  production  phase  having  successfully 
accomplished  all  developmental  and  operational  test  objectives. 

AP2.2.6.4.  Programs  for  which  planned  test  and  evaluation  is  only  a  part  of  routine 
aging  and  surveillance  testing,  service  life  monitoring,  or  tactics  development. 

AP2.2.6.5.  Programs  for  which  no  further  operational  testing  or  live  fire  testing  is 
required  by  any  DoD  Component. 

AP2.2.6.6.  Program  for  which  fiiture  testing  (e.g.,  product  improvements  or  block 
upgrades)  has  been  incorporated  in  a  separate  TEMP  (e.g.,  an  upgrade  TEMP). 

AP2.2.7.  Requesting  Cancellation  of  TEMP  Requirement.  Written  requests  for  cancellation 
of  a  TEMP  requirement  must  be  forwarded  to  the  Component  TEMP  approval  authority,  or,  for 
TEMPS  vmder  OSD  T&E  oversight,  through  the  Component  TEMP  approval  authority  to  the 
cognizant  OIPT  leader.  Justification,  such  as  applicability  of  any  the  above  circumstances,  must 
be  included  in  the  request.  The  cognizant  OIPT  leader  will  jointly  review  the  request  with 
DOT&E  and  notify  the  Component  TEMP  approval  authority  of  the  result. 

AP2.3.  MANDATORY  FORMAT 

The  mandatory  TEMP  format  for  all  ACAT  I  pro^ams,  for  IT,  including  NSS,  programs 
regardless  of  ACAT,  and  for  other  DOT&E-oversight  programs  begins  on  the  next  page. 
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TEST  AND  EVALUATION  MASTER  PLAN 
FOR 

PROGRAM  TITLE/SYSTEM  NAME 


Program  Elements 
Xxxxx 

SUBMITTED  BY 


Program  Manager  DATE 

CONCURRENCE 


Program  Executive  Officer  DATE 

or  Developing  Agency  (if  not  under  the  PEO  structure) 


Operational  Test  Agency  DATE 


User's  Representative  DATE 

COMPONENT  APPROVAL 


Component  Test  and  Evaluation  Director  DATE 


DoD  Component  Aequisition  Executive  (ACAT  I)  DATE 
Milestone  Decision  Authority  (for  less-than-ACAT  I) 

s|e:|«:jc:|c H«**********  Hi*  *******Hs*******J|e*5!sHJ******5H5!!5|«H«JH5ie**5is*****5l:***5H**HsHe*5i«*H!Hs 

OSD  APPROVAL 


Director,  Date  Cognizant  OIPT  Date 

Operational  Test  and  Leader 

Evaluation 
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1.  PART  T-SYSTEM  INTRODUCTION 

a.  Mission  Description  Reference  the  MNS,  CRD  (if  applicable),  C4ISP,  and  ORD. 
Briefly  summarize  the  mission  need  described  therein.  Describe  the  mission  in  terms  of 
objectives  and  general  capabilities.  Include  a  description  of  the  operational  and  logistical 
environment  envisioned  for  the  system. 

b.  System  Description  Briefly  describe  the  system  design,  to  include  the  following 
items: 

(1)  Key  features  and  subsystems,  both  hardware  and  software  (such  as  architecture, 
interfaces,  security  levels,  reserves)  for  each  block/configuration,  allowing  the  system  to  perform 
its  required  operational  mission. 

(2)  Interfaces  with  existing  or  planned  systems  that  are  required  for  mission 
accomplishment.  Address  relative  maturity  and  integration  and  modification  requirements  for 
non-developmental  items.  Include  interoperability  with  existing  and/or  planned  systems  of  other 
DoD  Components  or  allies.  Provide  a  diagram  of  the  system  architecture. 

(3)  Critical  system  characteristics  or  unique  support  concepts  resulting  in  special  test  and 
analysis  requirements  (e.g.,  post  deployment  software  support,  hardness  against  nuclear  effects; 
resistance  to  cormtermeasures;  resistance  to  reverse  engineering/exploitation  efforts  (Anti- 
Tamper);  development  of  new  threat  simulation,  simulators,  or  targets). 

c.  System  Threat  Assessment.  Reference  the  System  Threat  Assessment  and  briefly 
summarize  the  threat  environment  described  therein. 

d.  Measxires  of  Effectiveness  and  Suitability.  List  (see  example  matrix  below)  the 
performance  (operational  effectiveness  and  suitability)  capabilities  identified  as  required  in  the 
ORD.  The  critical  operational  effectiveness  and  suitability  parameters  and  constraints  must 
crosswalk  to  those  used  in  the  Analysis  of  Alternatives,  and  include  manpower,  personnel, 
training,  software,  computer  resources,  transportation  (lift),  compatibility,  interoperability  and 
integration.  Information  Assurance  (LA),  Electromagnetic  Environmental  Effects  and  Spectrum 
Supportability,  etc.  Focus  on  operational  capabilities,  not  design  specifications  such  as  weight, 
size,  etc.  Limit  the  list  to  critical  measures  that  apply  to  capabilities  essential  to  mission 
accomplishment.  Include  and  clearly  identify  all  Key  Performance  Parameters  (KPP).  For  each 
listed  parameter,  provide  the  threshold  and  the  objective  values  from  the  ORD  and  the  ORD 
reference.  If  the  Operational  Test  Agency  (OTA)  or  the  DOT&E  determines  that  the  required 
capabilities  and  characteristics  contained  in  the  ORD  provide  insufficient  measures  for  an 
adequate  OT&E,  the  OTA  or  DOT&E  shall  propose  additional  measures  through  the  IPT 
process.  Upon  receipt  of  such  a  proposal,  the  ORD  approval  authority  shall  establish  the  level  of 
required  performance  characteristics. 
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Measures  of  Effectiveness  and  Suitability 


Operational 

Requirement 

Parameter 

ORD 

Threshold 

ORD 

Objective 

ORD 

Reference 

Mobflity 

Land  Speed** 
Miles  per  hour 
on  secondary 
roads 

XX  miles  per 
hour 

XX  miles  per 
hour 

Paragraph  xxx ' 

Firepower 

Accuracy 

Main  Gun 
Probability  of 
hit/stationary 
platform/ 
stationary  target 

XXX  probability 
of  hit  @  XXX 
range 

XXX  probability 
of  hit  @  XXX 
range 

Paragraph  xxx 

Supportability 

Reliability 

Mean  Time 
Between 
Operational 
Failure 

XXX  hours 

XXX  hours 

Paragraph  xxx 

**  Key  Performance  Parameter 


e.  Critical  Technical  Parameters 

(1)  List  in  a  matrix  format  (see  example  below)  the  critical  techmcal  parameters  of  the 
sys-tem  (including  software  maturity  and  performance  measures)  that  will  be  evaluated  (or 
reconfirmed  if  previously  evaluated)  during  the  remaining  phases  of  developmental  testing.  In 
accordance  with  section  C3.5.  of  this  Regulation,  include  the  maturity  criteria  and  performance 
exit  criteria  necessary  for  operational  test  readiness  certification.  Critical  technical  parameters 
are  measurable  critical  system  characteristics  that,  when  achieved,  allow  the  attainment  of 
operational  performance  requirements.  They  are  not  ORD  requirements.  Rather,  they  are 
technical  measures  derived  from  ORD  requirements.  Failure  to  achieve  a  critical  techmcal 
parameter  should  be  considered  a  reliable  indicator  that  the  system  is  behind  in  the  planned 
development  schedule  or  will  likely  not  achieve  an  operational  requirement.  Lumt  the  list  of 
critical  technical  parameters  to  those  that  support  critical  operational  issues.  The  system 
specification  is  usually  a  good  reference  for  the  identification  of  critical  technical  parameters. 
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(2)  Next  to  each  technical  parameter,  list  a  threshold  for  each  stage  of  development. 
Developmental  test  events  are  opportunities  to  measure  the  performance  of  the  system  as  it 
matures.  For  most  technical  parameters,  the  listed  thresholds  should  reflect  growth  as  the  system 
progresses  toward  achieving  its  ORD  requirements.  Also,  list  the  decision  supported  after  each 
event  to  highlight  technical  performance  required  before  entering  the  next  acquisition  or 
operational  test  phase. 

(3)  Ensure  technical  parameters  are  included  for  technical  interoperability. 
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Critical  Technical  Parameters 


Supported 

Operational 

Requirement 

(Include 

ORD 

reference) 

Technical 

Parameter 

Developmental 
Stage  Event 

Threshold 

Value 

DecisionSupported 

In  most  cases 
a  measure  of 
effectiveness 
or  suitability 
from 

paragraph  Id 

Technical 

measure(s) 

derived  to 

support 

operational 

requirement 

Developmental 
stage  events 
(Described  in 
TEMP  Part  III) 
designed  to 
measure  system 
performance 
against 
technical 
parameters. 

Minimum 
value  required 
at  each 

developmental 
event.  Most 
parameters 
will  show 
growth  as  the 
system 
progress 
through 
testing.  Final 
value  should 
reflect  level  of 
performance 
necessary  to 
satisfy  the 
operational 
requirement. 

May  be  any  decision 
marking  the 
entrance  into  a  new 
acquisition  phase  or 
may  be  a  readiness 
for  operational  test 
decision. 

Example: 

Main  Gim 
Probability  of 
Hit,  94  %  at 
1,500  meters 
(ORD  para. 
xxx.x) 

Example: 

Auxiliary 

sight 

Boresight 

accuracy 

Example: 

System  Demo 

Test-Accuracy 

Test 

Prod  Readiness 
Test-Accuracy 

Prod  Qual  Test 

Example 

+/-  5  mils 

+/-  3  mils 

+/- 1  mil 

Example 

Milestone  B 

MS  C  (Low  Rate 
Initial  Production 
Decision) 

FRP  DR 
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2.  PART  II-INTEGRATED  TEST  PROGRAM  SUMMARY 

a.  Integrated  Test  Program  Schedule 

(1)  Display  on  a  chart  (see  Figure  1)  the  integrated  time  sequencing  of  the  major  test  and 
evaluation  phases  and  events,  related  activities,  and  planned  cumulative  funding  expenditures  by 
appropriation. 

(2)  Include  event  dates  such  as  major  decision  points  as  defined  in  DoDI  5000.2; 
operational  assessments,  preliminary  and  critical  design  reviews,  test  article  availability; 
software  version  releases;  appropriate  phases  of  developmental  test  and  evaluation;  live  fire  test 
and  evaluation,  JITC  interoperability  testing  and  certification  date  to  support  FRP  Decision 
Review,  and  operational  test  and  evaluation;  low  rate  initial  production  deliveries;  Initial 
Operational  Capability;  Full  Operational  Capability;  and  statutorily  required  reports,  such  as  the 
Live-Fire  T&E  Report  and  Beyond-LRIP  Report. 

(3)  A  single  schedule  shall  be  provided  for  multi-Service  or  Joint  and  Capstone  TEMPs 
showing  all  DoD  Component  system  event  dates. 

(4)  Provide  the  date  (fiscal  quarter)  when  the  decision  to  proceed  beyond  low-rate  initial 
production  is  planned.  (LRIP  quantities  required  for  initial  operational  test  must  be  identified  for 
approval  by  the  DOT&E  prior  to  entry  into  System  Development  and  Demonstration  Phase  for 
ACAT  I  programs  and  other  programs  designated  for  DOT&E  oversight). 

b.  Management 

(1)  Discuss  the  test  and  evaluation  responsibility  of  all  participating  organizations 
(developers,  testers,  evaluators,  users). 

(2)  Identify  the  T&E  IPT  structure,  to  include  the  sub-IPTs,  such  as  a  Modeling  & 
Simulation  WIPT  or  Reliability  WIPT,  with  their  participating  organizations.  A  more  detailed 
discussion  can  be  contained  in  a  separate  T&E  charter;  however,  sufficient  detail  is  needed  here 
for  those  persons  not  having  convenient  access  to  the  charter. 

(3)  Provide  the  proposed  or  approved  performance  Exit  Criteria  to  be  assessed  at  the  next 
major  decision  point.  For  a  TEMP  update,  generated  by  a  program  breach  or  significant  change, 
provide  the  Acquisition  Decision  Memorandum-approved  Exit  Criteria  from  the  current  phase’s 
beginning  milestone  decision,  or  any  revised  ones  generated  by  the  breach  or  significant  change. 

3.  PART  m-DEVELOPMENTAL  TEST  AND  EVALUATION  OUTLINE 

a.  Developmental  Test  and  Evaluation  Overview.  Explain  how  developmental  test  and 
evaluation  will:  verify  the  status  of  engineering  and  manufacturing  development  progress;  verify 
that  design  risks  have  been  minimized;  and  that  anti-tamper  provisions  have  been  implemented; 
substantiate  achievement  of  contract  technical  performance  requirements;  and  be  used  to  certify 
readiness  for  dedicated  operational  test.  Specifically,  identify: 
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(1)  Any  technology/subsystem  that  has  not  demonstrated  its  ability  to  contribute  to  system 
performance  and  ultimately  fulfill  mission  requirements. 

(2)  The  degree  to  which  system  hardware  and  software  design  has  stabilized  so  as  to 
reduce  manufacturing  and  production  decision  uncertainties. 

b.  Future  Developmental  Test  and  Evaluation  Discuss  all  remaining  developmental  test 
and  evaluation  that  is  planned,  beginning  with  the  date  of  the  current  TEMP  revision  and 
extending  through  completion  of  production.  Place  emphasis  on  the  next  phase  of  testing.  For 
each  phase,  include: 

(1)  Configuration  Description.  Siraunarize  the  functional  capabilities  of  the  system's 
developmental  configuration  and  how  they  differ  from  the  production  model. 

(2)  Developmental  Test  and  Evaluation  Objectives.  State  the  test  objectives  for  this  phase 
in  terms  of  the  critical  technical  parameters  to  be  confirmed,  to  include  anti-tamper 
characteristics.  Identify  any  specific  technical  parameters  that  the  milestone  decision  authority 
has  designated  as  exit  criteria  and/or  directed  to  be  demonstrated  in  a  given  phase  of  testing. 

(3)  Developmental  Test  and  Evaluation  Events,  Scope  of  Testing,  and  Basic  Scenarios. 
Summarize  the  test  events,  test  scenarios  and  the  test  design  concept.  Quantify  the  testing  (e.g., 
number  of  test  hours,  test  events,  test  firings).  List  the  specific  threat  systems,  surrogates, 
countermeasures,  component  or  subsystem  testing,  and  testbeds  which  are  critical  to  determine 
whether  or  not  developmental  test  objectives  are  achieved.  As  appropriate,  particularly  if  an 
agency  separate  fi'om  the  test  agency  will  be  doing  a  significant  part  of  the  evaluation,  describe 
the  methods  of  evaluation.  List  all  models  and  simulations  to  be  used  to  evaluate  the  system’s 
performance,  explain  the  rationale  for  their  credible  use  and  provide  their  source  of  verification, 
validation  and  accreditation  (W&A).  Describe  how  performance  in  natural  environmental 
conditions  representative  of  the  intended  area  of  operations  (e.g.,  temperature,  pressure, 
humidity,  fog,  precipitation,  clouds,  electromagnetic  environment,  blowing  dust  and  sand,  icing, 
wind  conditions,  steep  terrain,  wet  soil  conditions,  high  sea  state,  storm  surge  and  tides,  etc.)  and 
interoperability  with  other  weapon  and  support  systems,  as  applicable,  to  include  insensitive 
munitions,  will  be  tested.  Describe  the  developmental  test  and  evaluation  plans  and  procedures 
that  will  support  the  JITC/DISA  interoperability  certification  recommendation  to  the  Director, 
Joint  Staff  (J-6)  in  time  to  support  the  FRP  Decision  Review. 

(4)  Limitations.  Discuss  the  test  limitations  that  may  significantly  affect  the  evaluator's 
ability  to  draw  conclusions,  the  impact  of  these  limitations,  and  resolution  approaches. 

4.  PART  TV-OPERATTONAI.  TEST  AND  EVALUATION  OUTLINE 

a.  Operational  Test  and  Evaluation  Overview 

(1)  The  primary  purpose  of  operational  test  and  evaluation  is  to  determine  whether 
systems  are  operationally  effective  and  suitable  for  the  intended  use  by  representative  users  in  a 
realistic  environment  before  production  or  deployment. 
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(2)  The  TEMP  shall  show  how  program  schedule,  test  management  structure,  and 
required  resources  are  related  to  operational  requirements  documented  in  the  certified  CRD  (if 
applicable)  and  ORD,  and  derived  requirements  from  the  C4ISP;  critical  operational  issues;  test 
objectives;  and  major  decision  points.  Testing  shall  evaluate  the  system  (operated  by  t3q)ical 
users)  in  an  environment  as  operationally  realistic  as  possible,  including  threat  representative 
hostile  forces  and  the  expected  range  of  natural  environmental  conditions. 

b.  Critical  Operational  Issues 

(1)  List  in  this  section  the  critical  operational  issues.  Critical  operational  issues  are  the 
operational  effectiveness  and  operational  suitability  issues  (not  parameters,  objectives  or 
thresholds)  that  must  be  examined  in  operational  test  and  evaluation  to  evaluate/assess  the 
system's  capability  to  perform  its  mission. 

(2)  A  critical  operational  issue  is  typically  phrased  as  a  question  that  must  be  answered  in 
order  to  properly  evaluate  operational  effectiveness  (e.g.,  "Will  the  system  detect  the  threat  in  a 
combat  environment  at  adequate  range  to  allow  successful  engagement?")  and  operational 
suitability  (e.g.,  "Will  the  system  be  safe  to  operate  in  a  combat  environment?") 

(3)  Some  critical  operational  issues  will  have  critical  technical  parameters  and  thresholds. 
Individual  attainment  of  these  attributes  does  not  guarantee  that  the  critical  operational  issue  will 
be  favorably  resolved.  The  judgment  of  the  operational  test  agency  is  used  by  the  DoD 
Component  to  determine  if  the  critical  operational  issue  is  favorably  resolved. 

(4)  State  the  measures  of  effectiveness  (MOEs)  and  measures  of  performance  (MOPs). 
Define  the  evaluation  criteria  and  data  requirements  for  each  MOE/MOP. 

(5)  If  every  critical  operational  issue  is  resolved  favorably,  the  system  should  be 
operationally  effective  and  operationally  suitable  when  employed  in  its  intended  environment  by 
typical  users. 

c.  Future  Operational  Test  and  Evaluation  For  each  remaining  phase  of  operational  test 
and  evaluation,  separately  address  the  following: 

(1)  Configuration  Description.  Identify  the  system  to  be  tested  during  each  phase,  and 
describe  any  differences  between  the  tested  system  and  the  system  that  will  be  fielded  including, 
where  applicable,  software  maturity  performance  and  criticality  to  mission  performance,  and  the 
extent  of  integration  with  other  systems  with  which  it  must  be  interoperable  or  compatible. 
Characterize  the  system  (e.g.,  prototype,  engineering  development  model,  production 
representative  or  production  configuration). 

(2)  Operational  Test  and  Evaluation  Objectives.  State  the  test  objectives  including  the 
objectives  and  thresholds  and  critical  operational  issues  to  be  addressed  by  each  phase  of 
operational  test  and  evaluation  and  the  decision  points  supported.  Operational  test  and 
evaluation  that  supports  the  beyond  low  rate  initial  production  decision  shall  have  test  objectives. 
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to  include  anti-tamper  characteristics  that  interface  with  operators  and  maintainers,  that  resolve 
all  unresolved  effectiveness  and  suitability  COIs. 

(3)  Operational  Test  and  Evaluation  Events,  Scope  of  Testing,  and  Scenarios.  Summarize 
the  scenarios  and  identify  the  events  to  be  conducted,  type  of  resources  to  be  used,  the  threat 
simulators  and  the  simulation(s)  to  be  employed,  the  type  of  representative  personnel  who  will 
operate  and  maintain  the  system,  the  status  of  the  logistic  support,  the  operational  and 
maintenance  documentation  that  will  be  used,  the  environment  xmder  which  the  system  is  to  be 
employed  and  supported  during  testing,  the  plans  for  interoperability  and  compatibility  testing 
with  other  United  States/Allied  weapon,  the  anti-tamper  characteristics  to  be  assessed  in  an 
operational  environment  and  support  systems  as  applicable,  etc.  Identify  planned  sources  of 
information  (e.g.,  developmental  testing,  testing  of  related  systems,  modeling,  simulation,  etc.) 
that  may  be  used  by  the  operational  test  agency  to  supplement  this  phase  of  operational  test  and 
evaluation.  Whenever  models  and  simulations  are  to  be  used:  identify  the  planned  models  and 
simulations;  explain  how  they  are  proposed  to  be  used;  and  provide  the  source  and  methodology 
of  the  verification,  validation,  and  accreditation  underlying  their  credible  application  for  the 
proposed  use.  If  operational  test  and  evaluation  cannot  be  conducted  or  completed  in  this  phase 
of  testing  and  the  outcome  will  be  an  operational  assessment  instead  of  an  evaluation,  this  shall 
clearly  be  stated  and  the  reason(s)  explained.  Describe  the  operational  test  and  evaluation  plans 
and  procedures  that  will  support  the  JITC/DISA  interoperability  certification  recommendation  to 
the  Director,  Joint  Staff  (J-6)  in  time  to  support  the  FRP  Decision  Review. 

(4)  Limitations.  Discuss  the  test  and  evaluation  limitations  including  threat  realism, 
resource  availability,  limited  operational  (military,  climatic,  nuclear,  etc.)  environments,  lumted 
support  environment,  maturity  of  tested  system,  safety,  etc.,  that  may  impact  the  resolution  of 
affected  critical  operational  issues.  Indicate  the  impact  of  the  test  and  evaluation  limitations  on 
the  ability  to  resolve  critical  operational  issues  and  the  ability  to  formulate  conclusions  regarding 
operational  effectiveness  and  operational  suitability.  Indicate  the  critical  operational  issues 
affected  in  parenthesis  after  each  limitation. 

d.  Live  Fire  Test  and  Evaluation*.  See  also  Appendix  C,  "LFT&E  Mandatory 
Procedures  and  Reports".  Include  a  description  of  the  overall  live  fire  test  and  evaluation 
strategy  for  the  item;  critical  live  fire  test  and  evaluation  issues;  required  levels  of  system 
protection  and  tolerance  to  terminal  effects  of  threat  weapons  and  lethality;  the  management  of 
the  live  fire  test  and  evaluation  program;  live  fire  test  and  evaluation  schedule,  funding  plans  and 
requirements;  related  prior  and  future  live  fire  test  and  evaluation  efforts;  the  evaluation 
approach  and  shot  selection  process;  and  major  test  and  evaluation  limitations  for  the  conduct  of 
live  fire  test  and  evaluation.  Discuss,  if  appropriate,  procedures  intended  for  obtaming  a  waiver 
from  full-up,  system-level  live  fire  testing  (realistic  survivability/lethality  testing  as  defined  in 
Section  2366,  Title  10  USC)  before  entry  into  the  System  Development  and  Demonstration 
Phase.  Live  fire  test  and  evaluation  resource  requirements  (including  test  articles  and 
instrumentation)  shall  be  appropriately  identified  in  the  Test  and  Evaluation  Resource  Summary. 
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*  Not  applicable  to  AIS  programs. 

5.  PART  V-TEST  AND  EVALUATION  RESOURCE  SUMMARY 

a.  Provide  a  summary  (preferably  in  a  table  or  matrix  format)  of  all  key  test  and 
evaluation  resources,  both  government  and  contractor,  that  will  be  used  during  the  course  of  the 
acquisition  program.  Specifically,  identify  the  following  test  resources: 

(1)  Test  Articles.  Identify  the  actual  number  of  and  timing  requirements  for  all  test 
articles,  including  key  support  equipment  and  technical  information  required  for  testing  in  each 
phase  by  major  type  of  developmental  test  and  evaluation  and  operational  test  and  evaluation.  If 
key  subsystems  (components,  assemblies,  subassemblies  or  software  modules)  are  to  be  tested 
individually,  before  being  tested  in  the  final  system  configuration,  identify  each  subsystem  in  the 
TEMP  and  the  quantity  required.  Specifically  identify  when  prototype,  engineering 
development,  pre-production,  or  production  models  will  be  used. 

(2)  Test  Sites  and  Instrumentation.  Identify  the  specific  test  ranges/facilities  to  be  used 
for  each  type  of  testing.  Compare  the  requirements  for  test  ranges/facilities  dictated  by  the  scope 
and  content  of  planned  testing  with  existing  and  programmed  test  range/facility  capability,  and 
highlight  any  major  shortfalls,  such  as  inability  to  test  under  representative  natural  environmental 
conditions.  Identify  instrumentation  that  must  be  acquired  specifically  to  conduct  the  plarmed 
test  program.  Describe  how  environmental  compliance  requirements  will  be  met. 

(3)  Test  Support  Equipment.  Identify  test  support  equipment  that  must  be  acquired 
specifically  to  conduct  the  test  program. 

(4)  Threat  Representation.  Identify  the  type,  munber,  availability,  and  fidelity 
requirements  for  all  representations  of  the  threat  to  be  used  in  testing.  Compare  the  requirements 
for  threat  representations  with  available  and  projected  assets  and  their  capabilities.  Highlight  any 
major  shortfalls.  Each  representation  of  the  threat  (target,  simulator,  model,  simulation  or  virtual 
simulation)  shall  be  subjected  to  validation  procedures  to  establish  and  document  a  baseline 
comparison  with  its  associated  threat  and  to  determine  the  extent  of  the  operational  and  techmcal 
performance  differences  between  the  two  throughout  the  life  cycle  of  the  threat  representation. 

(5)  Test  Targets  and  Expendables.  Identify  the  type,  number,  and  availability 
requirements  for  all  targets,  weapons,  flares,  chaff,  sonobuoys,  smoke  generators,  acoustic 
countermeasures,  etc.  that  will  be  required  for  each  phase  of  testing.  Identify  any  major 
shortfalls.  Each  threat  target  shall  be  subjected  to  validation  procedures,  tailored  to 
characteristics  of  interest,  in  order  to  establish  and  document  a  baseline  comparison  with  its 
associated  threat  and  to  ascertain  the  extent  of  operational  and  technical  performance  differences 
throughout  the  threat  target’s  life  cycle. 

(6)  Operational  Force  Test  Support.  For  each  test  and  evaluation  phase,  identify  the  type 
and  timing  of  aircraft  flying  hours,  ship  steaming  days,  and  on-orbit  satellite  contacts/coverage, 
and  other  critical  operating  force  support  required. 
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(7)  Simulations,  Models  and  Testbeds.  For  each  test  and  evaluation  phase,  identify  the 
models  and  simulations  to  be  used,  including  computer-driven  simulation  models  and 
hardware/software-in-the-loop  testbeds.  Identify  the  resources  required  to  accredit  their  usage. 

(8)  Special  Requirements.  Discuss  requirements  for  any  significant  non-instrumentation 
capabilities  and  resources  such  as:  special  data  processing/data  bases,  unique 
mapping/charting/geodesy  products,  extreme  physical  environmental  conditions  or 
restricted/special  use  air/sea/landscapes. 

(9)  Test  and  Evaluation  Funding  Requirements.  Estimate,  by  Fiscal  Year  and 
appropriation  line  number  (program  element),  the  funding  required  to  pay  direct  costs  of  planned 
testing.  State,  by  fiscal  year,  the  funding  currently  appearing  in  those  lines  (program  elements). 
Identify  any  major  shortfalls. 

{Id) Manpower/Personnel  Training.  Identify  manpower/personnel  and  training 
requirements  and  limitations  that  affect  test  and  evaluation  execution. 

b.  The  TEMP  shall  project  the  time-phased  test  and  test  support  resources  necessary  to 
accomplish  development,  integration  and  demonstration  testing  and  early  operational 
assessment.  The  TEMP  shall  estimate,  to  the  degree  known,  the  key  resources  necessary  to 
accomplish  developmental  test  and  evaluation,  operational  assessment,  live  fire  test  and 
evaluation,  and  operational  test  and  evaluation.  These  shall  include  test  and  training  ranges  of 
the  Major  Range  and  Test  Facility  Base  (MRTFB),  test  equipment  and  facilities  of  the  MRTFB, 
capabilities  designated  by  industry  and  academia,  unique  instrumentation,  threat  simulators, 
targets,  and  modeling  and  simulation.  As  system  acquisition  progresses,  the  preliminary  test 
resource  requirements  shall  be  reassessed  and  refined  and  subsequent  TEMP  updates  shall  reflect 
any  changed  system  concepts,  resource  requirements,  or  updated  threat  assessment.  Any 
resource  shortfalls  which  introduce  significant  test  limitations  shall  be  discussed  with  planned 
corrective  action  outlined. 

6.  Annex  A-RIBTJOGRAPHY 

a.  Cite  in  fliis  section  all  documents  referred  to  in  the  TEMP. 

b.  Cite  all  reports  documenting  technical,  live  fire,  and  operational  testing  and 
evaluation. 

7.  Annex  B-ACRONYMS 

List  and  define  acronyms  used  in  the  TEMP. 

8.  Annex  C-POfNTS  OF  CONTACT 

Provide  a  list  of  points  of  contact  as  illustrated  by  Figure  2. 
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ATTACHMENTS 
Provide  as  appropriate. 
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FIGURE  1  -  INTEGRATED  TEST  PROGRAM  SCHEDULE 


FIGURE  1  -  Integrated  Test  Program  Schedule 
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FIGURE  2  -  PROGRAM  POINTS  OF  CONTACT 

NAME  ORGANIZATION  TELEPHONE  (COMM/DSN) 
Service  Secretary/Agency  Director/Monitor/Coordinator 
User  Representative 
Program  Manager 

Developmental  Test  Director/Coordinator 
Operational  Test  Director/Coordinator 
OUSD(AT&L)/DT  Action  Officer 
OSD/DOT&E  Action  Officer 


E-MAIL  ADDRESS 
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APS.  APPENDIX  3 

LIVE  FIRE  TEST  AND  EVALUATION 
MANDATORY  PROCEDURES  &  REPORTS 


AP3.1.  INTRODUCTION  AND  PURPOSE 

APS.  1.1.  This  Appendix  provides  guidelines  to  describe  a  disciplined  management 
approach  for  the  conduct  of  LFT&E  within  DoD,  which,  if  followed,  will  enable  an  assessment 
of  a  system’s  vulnerability  and  lethality  and  ensure  compliance  with  LFT&E  legislation.  The 
legislation,  10  U.S.C.  2366,  contains  requirements  for  vulnerability  and  lethality  live  fire  testing 
of  covered  systems,  as  defined  in  this  regulation.  The  guidelines  describe  the  objective  and 
scope  of  LFT&E,  provide  guidance  for  LFT&E  planning,  testing,  evaluation,  and  documentation, 
and  discuss  the  responsibilities  of  LFT&E  principals. 

AP3.1.2.  The  objective  of  LFT&E  is  to  provide  a  timely  and  reasonable  assessment  of  the 
vulnerability/lethality  of  a  system  as  it  progresses  through  its  development  and  prior  to  fiill-rate 
production.  In  particular: 

AP3. 1.2.1.  To  provide  information  to  decision-makers  on  potential  user  casualties, 
vulnerabilities,  and  lethality,  taking  into  equal  consideration  susceptibility  to  attack  and  combat 
performance  of  the  system; 

AP3.1.2.2.  To  ensure  that  knowledge  of  user  casualties  and  system  vulnerabilities  or 
lethality  is  based  on  testing  of  the  system  under  realistic  combat  conditions; 

AP3. 1.2.3.  To  allow  any  design  deficiency  identified  by  the  testing  and  evaluation  to  be 
corrected  in  design  or  employment  before  proceeding  beyond  low-rate  initial  production;  and 

AP3. 1.2.4.  To  assess  battle  damage  repair  capabilities  and  issues  (while  assessment  of 
battle  damage  repair  capability  is  not  a  statutory  requirement  of  LFT&E,  test  officials  should 
exploit  opportunities  presented  by  LFT&E  to  assess  such  capabilities  whenever  prudent  and 
affordable). 

AP3.2.  DEFINITIONS 


The  legislation  covering  LFT&E  also  provides  definitions  of  “covered  system,”  “major 
munitions  program,”  “covered  product  improvement  programs,”  “realistic  survivability  testing,” 


Not  applicable  to  AIS 
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“realistic  lethality  testing,”  and  “configured  for  combat.”  The  definitions  of  “covered  system,” 
“major  mimitions  program,”  and  “covered  product  improvement  programs,”  are  encompassed  in 
the  single  DoD  term  “covered  system.” 

AP3.2.1.  Covered  System.  A  system  that  the  DOT&E,  acting  for  the  Secretary  of  Defense, 
has  determined  to  be: 

(A)  a  major  system  within  the  meaning  of  that  term  in  10  USC  2302(5)  that  is  -- 

(i)  user-occupied  and  designed  to  provide  some  degree  of  protection  to  its 
occupants  in  combat;  or 

(ii)  a  conventional  munitions  program  or  missile  program;  or 

(B)  a  conventional  munitions  program  for  which  more  than  1,000,000  rounds  are 
planned  to  be  acquired;  or 

(C)  a  modification  to  a  covered  system  that  is  likely  to  affect  significantly  the 
survivability  or  lethality  of  such  a  system. 

Note:  The  term  “covered  system”  as  defined  above  is  the  DoD  term  that  is  intended  to  include  all 
categories  of  systems  or  programs  identified  in  10  USC  2366  as  requiring  live  fire  test  and 
evaluation.  In  addition,  non-traditional  systems  or  programs  that  do  not  have  acquisition  points 
referenced  in  10  USC  2366,  but  otherwise  meet  the  statutory  criteria,  are  considered  “covered 
systems”  for  the  purpose  of  this  regulation. 

AP3.2.2.  Live  Fire  Test  and  Evaluation 

(A)  testing  within  a  DOT&E-approved  LFT&E  strategy  that  includes  the  firing  of 
actual  weapons  (or  surrogates  if  actual  threat  weapons  are  not  available)  at  components,  sub¬ 
systems,  sub-assemblies,  and/or  full-up,  system-level  targets  or  systems  to  examine  personnel 
casualties,  system  vulnerabilities,  or  system  lethality;  and 

(B)  he  evaluation  of  the  results  of  such  testing. 

(C)  For  purposes  of  this  regulation,  the  term  “live  fire  test  and  evaluation”  does  not 
include  an  assessment  based  exclusively  on: 

(i)  computer  modeling; 

(ii)  simulations;  or 

(iii)  analyses  of  system  requirements,  engineering  proposals,  design 
specifications,  or  any  other  information  contained  in  program  documents. 

Note:  10  USC  2366  requires  an  LFT&E  program  to  include  full-up,  system-level  testing  unless  a 
waiver  is  granted  in  accordance  with  statute  and  this  regulation. 

AP3.2.3.  Full-up,  System-Level  Test. 

(A)  vulnerability  testing  conducted,  using  munitions  hkely  to  be  encoimtered  in 
combat,  on  a  complete  system  loaded  or  equipped  with  all  the  dangerous  materials  that  normally 
would  be  on  board  in  combat  (including  flammables  and  explosives),  and  with  all  critical 
subsystems  operating  that  could  make  a  difference  in  determining  the  test  outcome;  or 
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(B)  lethality  testing  of  a  production-representative  munition  or  missile,  for  which  the 
target  is  representative  of  the  class  of  systems  that  includes  the  threat,  and  the  target  and  test 
conditions  are  sufficiently  realistic  to  demonstrate  the  lethal  effects  the  weapon  is  designed  to 
produce.  Note:  The  term  “full-up,  system-level  testing”  is  that  testing  that  folly  satisfies  the 
statutory  requirement  for  “realistic  survivability  testing”  or  “realistic  lethality  testing”  as  defined 
in  10  use  2366. 

AP3.2.4.  Survivability.  The  capability  of  a  system  and  crew  to  avoid  or  withstand  a  man¬ 
made  hostile  environment  without  suffering  an  abortive  impairment  of  its  ability  to  accomplish 
its  designated  mission.  Survivability  consists  of  susceptibility,  vulnerability,  and  recoverability. 

AP3.2.5.  Vulnerability.  The  characteristic  of  a  system  that  causes  it  to  suffer  a  definite 
degradation  (loss  or  reduction  of  capability  to  perform  its  designated  mission)  as  a  result  of 
having  been  subjected  to  a  certain  (defined)  level  of  effects  in  an  unnatural  (man-made)  hostile 
environment.  Vulnerability  is  considered  a  subset  of  survivability. 

AP3.2.6.  Lethality.  The  ability  of  a  munition  or  directed  energy  weapon  to  cause  damage 
that  will  cause  the  loss  or  a  degradation  in  the  ability  of  a  target  system  to  complete  its 
designated  mission(s). 

AP3.2.7.  Susceptibility.  The  degree  to  which  a  weapon  system  is  open  to  effective  attack 
due  to  one  or  more  inherent  weakness.  (Susceptibility  is  a  function  of  operational  tactics, 
countermeasures,  probability  of  enemy  fielding  a  threat,  etc.)  Susceptibility  is  considered  a 
subset  of  survivability. 

AP3.2.8.  Recoverability.  Following  combat  damage,  the  ability  to  take  emergency  action  to 
prevent  loss  of  the  system,  to  reduce  personnel  casualties,  or  to  regain  weapon  system  combat 
mission  capabilities. 

AP3.3.  IMPLEMENTATION 

AP3.3.1.  An  active,  well-planned,  well-managed  and  well-executed  LFT&E  strategy  is 
essential  to  understanding  system  vuhierability/lethality  and  shall  be  an  essential  element  of  the 
information  supporting  decisions  regarding  the  acquisition  of  materiel  as  well  as  the 
development  of  doctrine  for  its  proper  tactical  employment.  The  LFT&E  strategy  for  a  given 
system  shall  be  developed  as  soon  as  possible  after  Concept  Exploration,  and  be  structured  and 
scheduled  so  that  any  design  changes,  resulting  from  that  testing  and  analysis,  as  described  in  the 
strategy,  may  be  incorporated  before  proceeding  beyond  low-rate  initial  production.  LFT&E 
considerations  must  be  included  in  all  phases  of  the  weapon  system  acquisition  cycle,  begmning 
with  concept  exploration  and  continuing  until  Production  and  Support.  Furthermore,  the  LFT&E 
strategy  must  be  managed,  including  planning  and  programming,  in  such  a  manner  that  all 
elements  of  the  test  and  evaluation  process  are  well-integrated  and  complementary.  The 
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availability  of  facilities,  test  sites,  instrumentation,  personnel,  threat  targets,  munitions,  and/or 
directed  energy  weapons  shall  be  managed  throughout  all  phases  of  the  budget  cycle. 

AP3.3.2.  LFT&E  shall  be  initiated  as  early  as  possible  and  completed  before  entry  into  full- 
rate  production  and  deployment,  to  identify  and  assess  possible  design  deficiencies  so  that 
appropriate  corrective  actions  can  be  taken.  Beginning  with  component-level  testing  and 
analysis  during  component  advanced  development,  live  fire  vulnerability/lethality  test  and 
evaluation  continues  through  system  integration  and  system  demonstration  with  additional 
components/subsystem  testing,  and  progresses  to  full-up  system  level  LFT&E  of  production 
representative  items  (unless  a  waiver  from  flill-up,  system-level  testing  has  been  approved  in 
accordance  with  this  regulation)  before  the  system  proceeds  beyond  low-rate  initial  production 
(or  equivalent  point). 

AP3.3.3.  The  LFT&E  strategy  shall  be  structured  to  provide  a  timely  and  reasonable 
examination  and  understanding  of  the  vulnerability/lethality  of  U.S.  weapon  systems  and 
munitions/directed  energy  weapons  to  the  full  spectrum  of  validated  combat  threats/targets. 
Subsequent  product  improvements  to  covered  systems  meeting  the  statutory  criteria  are  also 
required  to  undergo  LFT&E  if  there  is  a  significant  impact  to  vulnerability  or  lethality.  If  any 
doubt  exists,  the  system  shall  be  assumed  to  be  covered  and  appropriate  action  taken.  This 
includes  waiver  action  if  full-up,  system-level  testing  would  be  unreasonably  expensive  and 
impractical.  All  LFT&E  of  covered  systems  is  conducted  by  the  Services  with  OSD  oversight. 

AP3.3.4.  LFT&E  of  all  systems  shall  be  predicated  upon  the  DoD  Intelligence  Community's 
official  assessment  of  the  principal  threat  systems  and  capabilities  an  adversary  might  reasonably 
bring  to  bear  in  an  attempt  to  defeat  or  degrade  a  specific  U.S.  system  as  described  in  the 
validated  threat  document. 

AP3.3.5.  Pretest  predictions  are  required  for  every  live  fire  test  event.  The  predictions  may 
be  based  on  computer  models,  engineering  principles,  or  engineering  judgment,  and  should 
address  a  level  of  detail  comparable  to  the  test  damage  assessment  methodology.  The  DOT&E- 
approved  LFT&E  strategy  shall  address  both  the  nature  of  the  pretest  predictions  and  the 
schedule  of  pretest  prediction  deliverables.  The  deliverables  and  supporting  documentation 
should  identify  basic  assumptions,  model  inputs,  and  known  limitations.  If  the  live  fire 
evaluation  plan  incorporates  the  use  of  vulnerability  or  lethality  models,  the  pretest  predictions 
should  exercise  those  models,  and  support  the  verification,  validation,  and  accreditation  of  those 
models. 

AP3.3.6.  The  generation  of  data  to  resolve  critical  LFT&E  issues  in  an  efficient  and  cost 
effective  manner  to  represent  realistic  environments  shall  be  of  paramount  concern  in  the  shot¬ 
line  selection  process  for  live  fire  testing.  While  an  element  of  randomness  in  shot-line  selection 
is  often  desirable,  total  reliance  on  complete  randomness  may  neither  be  consistent  with  the  test 
objectives  nor  be  an  efficient  use  of  test  resources.  Random  shot-lines  are  generated  from  a 
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realistic  distribution  of  hit  points,  to  include  such  factors  as  the  weapon  system  operator,  target 
signatures,  and  weapon  seeker  characteristics.  In  most  cases  a  mixture  of  random  shot-lines 
(shot-lines  generated  from  likely  hit  points)  and  engineering  shot-lines  (i.e.,  shot-lines 
specifically  selected  by  the  evaluator  to  address  specific  vulnerability/lethality  issues)  shall  be 
appropriate.  It  is  required  that  some  portion  of  the  total  shots  be  randomly  drawn  from  a  combat 
distribution  of  likely  hit  points,  when  known. 

AP3.3.7.  Although  the  evaluation  of  live  fire  test  results  will  address  kill  given  a  hit  (i.e., 
vulnerability  or  lethality),  the  outcome  of  LFT«&E  shall  not  necessarily  be  expressed  in  terms  of 
probabilities.  Rather,  live  fire  testing  shall  address  vulnerability  or  lethality  primarily  by 
examining  basic  damage  and  kill  mechanisms  and  their  interactions  with  the  target  system. 
Further,  the  evaluation  of  vulnerability  test  results  shall  address,  where  possible,  the 
susceptibility  of  the  system. 

AP3.3.8.  Although  LFT&E  programs  may  differ  significantly  in  scope  and  timing,  the  level 
of  maturity  at  various  stages  of  the  acquisition  process  is  basically  the  following;  during  Concept 
Exploration,  a  decision  shall  be  made  whether  the  system  meets  the  legislative  or  regulatory 
criteria  for  a  covered  system.  Initial  draft  strategies  shall  identify  proposed  issues,  existing  data 
in  support  of  the  issues,  and  live  fire  tests  to  be  conducted  throughout  the  acquisition  process. 

By  Milestone  B,  the  TEMP  must  contain  a  mature  strategy.  In  particular,  the  strategy  must 
either  commit  to  full-up,  system-level,  live  fire  testing,  or  a  waiver  request  and  alternative 
LFT&E  plan  must  have  been  submitted  and  approved.  The  entire  LFT&E  program,  to  include 
testing,  evaluation,  and  reporting,  must  be  completed  before  proceeding  beyond  low-rate  initial 
production. 

AP3.4.  RESPONSIBILITIES 

AP3.4.1.  USD(AT&L) 

AP3.4.1.1.  For  a  covered  system  acquisition  program  lacking  traditional  milestones 
cited  in  10  USC  2366,  designates  equivalent  events  for  the  purpose  of  applying  the  schedule 
requirements  for  LFT&E. 

AP3.4.1.2.  May  waive  the  requirement  for  full-up,  system-level  LFT&E  in  accordance 
with  the  provisions  of  10  USC  2366,  following  DOT&E  approval  of  the  alternative  LFT&E  plan. 
In  such  a  case,  must  certify  in  writing  to  the  Congressional  defense  committees,  before  the 
system  enters  System  Development  and  Demonstration  (or  equivalent  point),  that  full-up, 
system-level  testing  would  be  unreasonably  expensive  and  impracticable,  and  include  the 
DOT&E-approved  alternative  plan.  Note:  The  waiver  decision  authority  is  the  CAE  for  less-than 
ACAT  ID  programs. 
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AP3.4.2.  DOT&E 

AP3.4.2.1.  Serves  as  the  OSD  focal  point  for  review,  coordination,  and  approval  of 
LFT&E  policy. 

AP3 .4.2.2.  Approves  LFT&E  strategies,  as  provided  in  the  TEMP  or  equivalent 
document,  and  alternative  LFT&E  plans,  when  applicable,  in  support  of  a  waiver  from  full-up, 
system-level  testing. 

AP3 .4.2.3.  Designates  covered  systems  for  LFT&E  that  meet  the  regulatory  criteria. 
Annually  reviews  all  potential  systems  for  inclusion  or  deletion  from  the  OSD  T&E  Oversight 
List. 


AP3.4.2.4.  Approves  Services’  LFT&E  planning  documents  as  identified  for  DOT&E 
approval  in  the  LFT&E  planning  matrix  included  in  the  TEMP. 

AP3.4.2.5.  Reviews  Services’  LFT&E  planning  documents  not  requiring  DOT&E 
approval,  as  identified  in  the  LFT&E  planning  matrix  included  in  the  TEMP. 

AP3.4.2.6.  Reviews  Services'  LFT&E  Reports. 

AP3.4.2.7.  Monitors  and  reviews  the  Services'  LFT&E  program  during  its  conduct. 

AP3.4.2.8.  Submits  an  independent  LFT&E  report  for  each  covered  system  (to  include 
LFT&E  programs  conducted  under  the  waiver  provisions  of  10  USC  2366)  to  the  Secretary  of 
Defense  and,  as  delegated  by  the  Secretary,  to  the  Congress  before  a  covered  system  can  proceed 
beyond  low-rate  initial  production. 

AP3 .4.2.9.  Describes  and  assesses  the  status  of  LFT&E  activities  for  each  system 
requiring  LFT&E  as  part  of  the  DOT&E  annual  report  to  Congress  required  by  10  USC  139. 

AP3.4.3.  DoD  Components 

AP3. 4.3.1.  Recommend  candidate  covered  systems  for  LFT&E. 

AP3.4.3.2.  Develop  and  implement  the  LFT&E  strategy  for  each  affected  system  and 
ensures  this  strategy  is  fully  described  in  the  TEMP. 

AP3.4.3.3.  Plan,  program,  and  budget  research,  development,  test  and  evaluation  and 
other  procurement  funds  in  support  of  LFT&E  including  the  acquisition  of  threat 
targets/munitions  or  acceptable  surrogates. 
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APS .4.3. 4.  Identify  critical  LFT&E  issues,  prepare  and  approve  required  plans,  reports 
and  other  dociunentation. 

AP3.4.3.5.  Permit  DOT&E  to  monitor,  on-site,  all  LFT&E  tests. 

AP3.4.3.6.  Conduct  engineering  assessments  of  possible  design  changes  resulting  from 
LFT&E  and  develop  programs  for  incorporating  cost  effective  design  changes  as  early  as 
possible  commensurate  with  the  system  acquisition  strategy. 

AP3.4.3.7.  Submit  alternative  LFT&E  strategy  for  approval  to  the  Director,  OT&E,  if 
fiill-up,  system-level  testing  would  be  unreasonably  expensive  and  impracticable. 

AP3.4.3.8.  Submit  request  for  waiver  from  full-up,  system-level  testing  for  approval  to 
the  USD(AT&L)  for  ACAT  ID  programs,  or  to  the  CAE  for  less-than  ACAT  ID  programs,  if 
full-up,  system-level  testing  would  be  unreasonably  expensive  and  impracticable.  Include  a  copy 
of  the  approved  alternative  plan  with  the  request  for  waiver. 

AP3.4.3.9.  Manage  Service  facilities  and  resources  and  provide  guidance  on  operating 
these  test  facilities  to  support  LFT&E. 

AP3.5.  LFT&E  DOCUMENTS 

Conduct  of  LFT&E  shall  require  the  preparation  and  submission  to  OSD  of  the  following  listed 
documents.  Additional  documentation  may  be  prepared  as  part  of  the  developmental  process  to 
support  engineering  tests  that  bear  on  the  live  fire  test  assessment.  Review  and  approval  of 
additional  documentation  shall  be  at  the  Service  level. 

AP3.5.1.  TEMP.  The  TEMP  summarizes  where,  when,  and  how  the  LFT&E  issues  will  be 
tested/evaluated.  Specific  LFT&E  items  considered  for  inclusion  in  the  TEMP  are:  a  description 
of  the  overall  live  fire  test  and  evaluation  strategy  for  the  item;  critical  live  fire  test  and 
evaluation  issues;  required  levels  of  system  vulnerability/lethality;  the  management  of  the  live 
fire  test  and  evaluation  program;  live  fire  test  and  evaluation  schedule,  funding  plans  and 
requirements;  related  prior  and  future  live  fire  test  and  evaluation  efforts;  the  evaluation  plan  and 
shot  selection  process;  modeling  and  simulation  strategy  and  W&A;  and  major  test  limitations 
for  the  conduct  of  live  fire  test  and  evaluation.  Live  fire  test  and  evaluation  resource 
requirements  (including  test  articles  and  instrumentation)  shall  be  appropriately  identified  early 
in  the  development  cycle  and  appear  in  the  Test  and  Evaluation  Resource  Summary.  The  TEMP 
shall  include  an  LFT&E  planning  matrix  that  covers  all  tests  within  the  LFT&E  strategy,  their 
schedules,  the  issues  they  will  address  and  which  planning  documents  the  Services  propose  for 
submission  to  DOT&E  for  approval  and  which  are  proposed  to  be  submitted  for  information  and 
reviews  only.  (See  also  Appendix  B). 
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AP3.5.2.  Detailed  Test  and  Evaluation  Plan.  This  document  describes  the  detailed  test 
procedures,  test  conditions,  data  collection,  and  analysis  processes  to  be  used  during  the  conduct 
of  each  live  fire  test.  Annex  B  provides  additional  detail  on  the  content  of  the  detailed  test  and 
evaluation  plans  required  for  the  full-up,  system-level  live  fire  tests.  The  detailed  test  and 
evaluation  plan  shall  be  submitted  to  DOT&E  for  comment  at  least  30  days  before  test  initiation. 
DOT&E  shall  have  15  days  for  submission  of  comments  subsequent  to  its  receipt  of  the  detailed 
test  plan/evaluation  plan. 

AP3.5.3.  Detailed  Test  and  Evaluation  Report.  The  results  and  overall  evaluation  of  all 
testing,  identified  in  the  LFT&E  strategy,  shall  be  documented  by  the  Service  and  submitted  to 
DOT&E  no  later  than  120  days  after  test  completion.  The  format  of  the  Report(s)  is  a  Service 
option;  however,  to  facilitate  the  DOT&E  independent  report  to  Congress,  each  Service  report 
shall  include  the  firing  results,  test  conditions,  a  description  of  any  deviations  approved 
subsequent  to  the  preparation  of  the  detailed  test  and  evaluation  plan,  test  limitations, 
conclusions,  and  the  evaluation  of  live  fire  vulnerability/lethality  based  on  available  information 
(if  applicable).  DOT&E  shall  have  45  days,  from  receipt  of  the  final  Service  detailed  test  and 
evaluation  report,  for  preparation  and  transmittal,  as  delegated  by  the  Secretary,  of  the  Secretary 
of  Defense  assessment  report  to  Congress.  Service  technical  review  is  normally  requested  prior 
to  transmittal. 

AP3.6.  WAIVERS 

As  delegated  by  the  Secretary  of  Defense,  waivers  from  full-up,  system-level  LFT&E  are 
approved  prior  to  Milestone  B  (or  equivalent  point)  by  USD(AT&L),  for  ACAT  ID  programs,  or 
by  the  appropriate  CAE,  for  less  than  ACAT  ID  programs,  provided  the  requirements  of  Section 
3.7  of  this  Regulation  are  met.  With  the  exception  of  the  requirements  for  full-up,  system-level, 
live  fire  testing,  the  requirements  for  waived  LFT&E  programs  are  no  less  stringent  than  for  non- 
waived  programs,  to  include  the  inclusion  of  an  LFT&E  strategy  in  the  TEMP  and  an 
independent  DOT&E  assessment  report  to  Congress,  as  delegated  by  the  Secretary  of  Defense. 
Waivers  from  fiill-up,  system-level,  live  fire  testing  (realistic  survivability/lethality  testing  as 
defined  in  10  USC  2366),  for  covered  systems,  including  product  improvements  that 
significantly  affect  survivability  or  lethality,  cannot  be  granted  after  Milestone  B  (or  equivalent 
point),  except  through  legislative  relief 
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ANNEX  A  -  REFERENCES 


1 .  Section  2366,  Title  10,  United  States  Code,  'Major  Systems  and  Munitions  Programs: 
Survivability  and  Lethality  Testing  Required  before  Full-Scale  Production.” 

2.  Department  of  Defense  Directive  5000.1,  “The  Defense  Acquisition  System.” 

3.  DoD  Instruction  5000.2,  “Operation  of  the  Defense  Acquisition  System.” 
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ANNEX  B  -  DETAILED  LIVE  FIRE  TEST  AND  EVALUATION  PLAN 

Mandatory  Content 


The  following  paragraphs  outline  the  mandatory  content  of  the  Detailed  Live  Fire  Test  and 
Evaluation  Plan.  No  standard  format  is  prescribed,  but  the  Plan  must  contain  at  least  the 
following  information: 

1.  A  cover  page  providing  the  name  of  the  system,  the  activity/agency  responsible  for 
preparation  of  the  Plan,  date,  classification,  and  applicable  distribution  statement. 

2.  A  coordination  sheet  containing  signatures  of  Service  approval  authorities. 

3.  Administrative  information:  name,  organization,  telephone,  and  E-Mail  addresses  of  key 
LFT&E  personnel. 

4.  Description  of  threat  weapons  or  targets  that  the  system  is  expected  to  encounter  during 
the  operational  life  of  the  system,  and  the  key  characteristics  of  these  threats/targets  that  affect 
system  vulnerability/lethality;  a  reference  to  the  specific  threat  definition  document  or  System 
Threat  Assessment;  a  discussion  of  the  rationale  and  criteria  used  to  select  the  specific 
threats/targets  and  the  basis  used  to  determine  the  number  of  threats/targets  to  be  tested  and 
evaluated  in  LFT&E. 

5.  If  actual  threats/targets  are  not  available,  then  the  plan  must  describe  the  threat/target 
surrogate  to  be  used  in  lieu  of  the  actual  threat/target,  and  the  rationale  for  its  selection. 

6.  A  statement  of  the  test  objectives  in  sufficient  detail  to  demonstrate  that  the  evaluation 
procedures  are  appropriate  and  adequate. 

7.  A  description  of  the  specific  threats/targets  to  be  tested  including  a  detailed  configuration 
and  stowage  plan  (to  include  payload  configuration)  for  each  shot.  Describe  the  rationale  or 
operational  scenarios  on  which  the  target  configuration/stowage  was  based. 

8.  A  listing  of  any  differences  between  the  system  to  be  tested  and  the  system  to  be  fielded. 
As  specifically  as  possible,  identify  the  degree  to  which  test  results  from  the  tested  configuration 
are  expected  to  be  representative  of  the  vulnerability  or  lethality  of  the  fielded  systems. 

9.  Identification  of  any  test  limitations,  particularly  any  potential  loss  of  realism  from 
absence  of  components,  arising  from  the  use  of  surrogates,  from  the  inerting  of  fuzes  on  stowed 
ammunition,  or  any  other  environmental,  safety,  health,  or  resource  constraints.  Identify  the 
impact  of  these  limitations  on  test  results. 
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10.  A  description  of  the  shot  selection  process.  Describe  the  process  to  be  used  to  establish 
the  test  conditions  for  randomly  selected  shots,  including  any  rules  ("exclusion  rules)  used  to 
determine  whether  a  randomly  generated  shot  may  be  excluded  from  testing.  For  engineering 
shots  (i.e.,  shots  selected  to  examine  specific  vulnerability/lethality  issues),  describe  the  issue 
and  the  associated  rationale  for  selecting  the  specific  conditions  for  these  shots.  List  the  specific 
impact  conditions  and  impact  points  for  each  shot,  and  whether  it  is  a  random  or  engineering 
shot. 

11.  A  detailed  description  of  the  test  approach,  test  setup,  test  conditions,  firing  procedures, 
damage  assessment  and  repair  process,  planned  test  sequence,  instrumentation,  data  collection 
and  analysis  procedures,  and  responsibilities  for  collecting  and  documenting  test  results.  Include 
any  standard  forms  that  will  be  used  to  document  test  results. 

12.  A  prediction  of  the  anticipated  results  of  each  shot.  These  predictions  may  be  based  on 
computer  models,  engineering  principles,  or  engineering  judgment.  Detail  shall  be  consistent 
with  the  technique  used  for  casualty/damage  prediction. 

13.  A  detailed  description  of  the  analysis/evaluation  plan  for  the  Live  Fire  Test.  The 
analysis/evaluation  plan  must  be  consistent  with  the  test  design  and  the  data  collected.  Indicate 
any  statistical  test  designs  used  for  direct  comparisons  or  for  assessing  any  pass/fail  criteria. 

14.  A  general  description,  including  applicable  references,  of  any  vulnerability/  lethality 
models  to  be  used  to  support  shot-line  selection,  pre-shot  predictions,  or  the  analysis/evaluation. 
This  material  shall  include  a  discussion  of  model  algorithm  or  input  limitations,  as  well  as 
references  to  the  sources  of  key  model  inputs. 

15.  A  detailed  description  of  the  approach  to  analyzing  and  mitigating  the  potential 
environmental  impacts,  consequences,  or  effects  of  the  test  activities,  unless  adequately 
described  elsewhere. 
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AP4.  APPENDIX  4 

EARNED  VALUE  MANAGEMENT  SYSTEMS  (EyMS) 
GUIDELINES.  MANDATORY  PROCEDURES.  &  REPORTING 


AP4.1.  INTRODUCTION  AND  PURPOSE 

Use  of  these  Earned  Value  Management  Systems  (EVMS)  guidelines  is  mandatory  on  selected 
contracts  (see  paragraph  C2. 9.3.4.).  The  contractors'  management  control  systems  shall  include 
policies,  procedures,  and  methods  that  are  designed  to  ensure  that  they  will  meet  the  guidelines 
shown  below.  These  guidelines  are  reproduced  from  the  American  National  Standards  Institute 
(ANSI)/Electronic  Industries  Alliance  (EIA)  EVMS  standard  (ANSI/EIA-748-98),  Chapter  2. 
Guidance  for  implementing  these  guidelines  on  DOD  contracts  can  be  formd  in  the  Earned  Value 
Management  Implementation  Guide  (EVMIG)  in  the  Defense  Acquisition  Deskbook. 

AP4.2.  ORGANIZATION 

AP4.2. 1 .  Define  the  authorized  work  elements  for  the  program.  A  work  breakdown 
stmcture  (WBS),  tailored  for  effective  internal  management  control,  is  commonly  used  in  this 
process. 

AP4.2.2.  Identify  the  program  organizational  structure  including  the  major  subcontractors 
responsible  for  accomplishing  the  authorized  work,  and  define  the  organizational  elements  in 
which  work  will  be  planned  and  controlled. 

AP4.2.3.  Provide  for  the  integration  of  the  company’s  planning,  scheduling,  budgeting, 
work  authorization  and  cost  accumulation  processes  with  each  other,  and  as  appropriate,  the 
program  work  breakdown  structure  and  the  program  organizational  structure. 

AP4.2.4.  Identify  the  company  organization  or  function  responsible  for  controlling 
overhead  (indirect  costs). 

AP4.2.5.  Provide  for  integration  of  the  program  work  breakdown  structure  and  the  program 
organizational  structure  in  a  manner  that  permits  cost  and  schedule  performance  measurement  by 
elements  of  either  or  both  stmctures  as  needed. 

AP4.3.  PLANNING.  SCHEDULING.  AND  BUDGETING 

AP4.3.1.  Schedule  the  authorized  work  in  a  manner  which  describes  the  sequence  of  work 
and  identifies  significant  task  interdependencies  required  to  meet  the  requirements  of  the 
program. 
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AP4.3.2.  Identify  physical  products,  milestones,  technical  performance  goals,  or  other 
indicators  that  will  be  used  to  measure  progress. 

AP4.3.3.  Establish  and  maintain  a  time-phased  budget  baseline,  at  the  control  account  level, 
against  which  program  performance  can  be  measured.  Initial  budgets  established  for 
performance  measurement  will  be  based  on  either  internal  management  goals  or  the  external 
customer  negotiated  target  cost  including  estimates  for  authorized  but  undefmitized  work. 

Budget  for  far-term  efforts  may  be  held  in  higher-level  accounts  until  an  appropriate  time  for 
allocation  at  the  control  account  level.  On  government  contracts,  if  an  over  target  baseline  is 
used  for  performance  measurement  reporting  purposes,  prior  notification  must  be  provided  to  the 
customer. 

AP4.3.4.  Establish  budgets  for  authorized  work  with  identification  of  significant  cost 
elements  (labor,  material,  etc.)  as  needed  for  internal  management  and  for  control  of 
subcontractors. 

AP4.3.5.  To  the  extent  it  is  practical  to  identify  the  authorized  work  in  discrete  work 
packages,  establish  budgets  for  this  work  in  terms  of  dollars,  hours,  or  other  measurable  units. 
Where  the  entire  control  account  is  not  subdivided  into  work  packages,  identify  the  far  term 
effort  in  larger  planning  packages  for  budget  and  scheduling  purposes. 

AP4.3.6.  Provide  that  the  sum  of  all  work  package  budgets  plus  planning  package  budgets 
within  a  control  account  equals  the  control  account  budget. 

AP4.3.7.  Identify  and  control  level  of  effort  activity  by  time-phased  budgets  established  for 
this  purpose.  Only  that  effort  which  is  unmeasurable  or  for  which  measurement  is  impractical 
may  be  classified  as  level  of  effort. 

AP4.3.8.  Establish  overhead  budgets  for  each  significant  organizational  component  of  the 
company  for  expenses,  which  will  become  indirect  costs.  Reflect  in  the  program  budgets,  at  the 
appropriate  level,  the  amounts  in  overhead  pools  that  are  planned  to  be  allocated  to  the  program 
as  indirect  costs. 

AP4.3.9.  Identify  management  reserves  and  undistributed  budget. 

AP4.3. 10.  Provide  that  the  program  target  cost  goal  is  reconciled  with  the  siim  of  all 
internal  program  budgets  and  management  reserves. 

AP4.4.  ACCOUNTING  CONSIDERATIONS 

AP4.4.1.  Record  direct  costs  in  a  manner  consistent  with  the  budgets  in  a  formal  system 
controlled  by  the  general  books  of  account. 
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AP4.4.2.  When  a  work  breakdown  structure  is  used,  summarize  direct  costs  from  control 
accounts  into  the  work  breakdown  structure  without  allocation  of  a  single  control  account  to  two 
or  more  work  breakdown  structure  elements. 

AP4.4.3.  Summarize  direct  costs  from  the  control  accounts  into  the  contractor's 
organizational  elements  without  allocation  of  a  single  control  account  to  two  or  more 
organizational  elements. 

AP4.4.4.  Record  all  indirect  costs  which  will  be  allocated  to  the  contract. 

AP4.4.5.  Identify  unit  costs,  equivalent  units  costs,  or  lot  costs  when  needed. 

AP4.4.6.  For  EVMS,  the  material  accounting  system  will  provide  for: 

AP4.4.6. 1 .  Accurate  cost  accumulation  and  allocation  of  costs  to  control  accounts  in  a 
manner  consistent  with  the  budgets  using  recognized,  acceptable,  costing  techniques. 

AP4.4.6.2.  Cost  performance  measurement  at  the  point  in  time  most  suitable  for  the 
category  of  material  involved,  but  no  earlier  than  the  time  of  progress  payments  or  actual  receipt 
of  material. 

AP4.4.6.3.  Full  accoruitability  of  all  material  purchased  and  all  material  transfers  for 
the  program,  including  the  residual  inventory. 

AP4.5.  ANALYSIS  AND  MANAGEMENT  REPORTS 

AP4.5.1.  At  least  on  a  monthly  basis,  generate  the  following  information  at  the  control 
account  and  other  levels  as  necessary  for  management  control  using  actual  cost  data  from,  or 
reconcilable  with,  the  accounting  system: 

AP4.5. 1 . 1 .  Comparison  of  the  amount  of  planned  budget  and  the  amount  of  budget 
earned  for  work  accomplished.  This  comparison  provides  the  schedule  variance. 

AP4.5. 1 .2.  Comparison  of  the  amount  of  the  budget  earned  and  the  actual  (applied 
where  appropriate)  direct  costs  for  the  same  work.  This  comparison  provides  the  cost  variance. 

AP4.5.2.  Identify,  at  least  monthly,  the  significant  differences  between  both  planned  and 
actual  schedule  performance  and  planned  and  actual  cost  performance,  and  provide  the  reasons 
for  the  variances  in  the  detail  needed  by  program  management. 

AP4.5.3.  Identify  budgeted  and  applied  (or  actual)  indirect  costs  at  the  level  and  frequency 
needed  by  management  for  effective  control,  along  with  the  reasons  for  any  significant 
variances. 
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AP4.5.4.  Summarize  the  data  elements  and  associated  variances  through  the  program 
organization  and/or  work  breakdown  structure  to  support  management  needs  and  any  customer 
reporting  specified  in  the  contract. 

AP4.5.5.  Implement  managerial  actions  taken  as  the  result  of  earned  value  information. 

AP4.5.6.  Develop  revised  estimates  of  cost  at  completion  based  on  performance  to  date, 
commitment  values  for  material,  and  estimates  of  future  conditions.  Compare  this  information 
with  the  performance  measurement  baseline  to  identify  variances  at  completion  important  to 
company  management  and  any  applicable  customer  reporting  requirements  including  statements 
of  funding  requirements. 

AP4.6.  REVISIONS  AND  DATA  MAINTENANCE 

AP4.6. 1 .  Incorporate  authorized  changes  in  a  timely  manner,  recording  the  effects  of  such 
changes  in  budgets  and  schedules.  In  the  directed  effort  prior  to  negotiation  of  a  change,  base 
such  revisions  on  the  amount  estimated  and  budgeted  to  the  program  organizations. 

AP4.6.2.  Reconcile  current  budgets  to  prior  budgets  in  terms  of  changes  to  the  authorized 
work  and  internal  replanning  m  the  detail  needed  by  management  for  effective  control. 

AP4.6.3.  Control  retroactive  changes  to  records  pertaining  to  work  performed  that  would 
change  previously  reported  amounts  for  actual  costs,  earned  value,  or  budgets.  Adjustments 
should  be  made  only  for  correction  of  errors,  routine  accoimting  adjustments,  effects  of  customer 
or  management  directed  changes,  or  to  improve  the  baseline  integrity  and  accuracy  of 
performance  measurement  data. 

AP4.6.4.  Prevent  revisions  to  the  program  budget  except  for  authorized  changes. 

AP4.6.5.  Document  changes  to  the  performance  measurement  baseline. 
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AP5.  APPENDIX  5 

COMMAND.  CONTROL.  COMMUNICATION. 
COMPUTERS.  AND  INTELLIGENCE  (C4D 
SUPPORT  PLAN  rC4ISP') 
MANDATORY  PROCEDURES  AND  FORMATS 


AP5.1.  INTRODUCTION  AND  PURPOSE 

APS.  1.1.  This  appendix  provides  the  mandatory  format  and  review  process  for  the  C4ISP, 
required  by  DoDI  5000.2,  and  by  DoD  5000.2-R,  Section  C6.4.  The  C4ISP  provides  a 
mechanism  to  identify  and  resolve  implementation  issues  related  to  an  acquisition  program’s 
C4ISR  infrastructure  support  and  IT  system,  including  NSS,  interface  requirements.  It  identifies 
C4ISR  needs,  dependencies,  and  interfaces  for  programs  in  all  acquisition  categories,  focusing 
attention  on  interoperability,  supportability,  and  sufficiency  concerns.  Interoperability  is  defined 
in  DoD  Instruction  5000.2  and  in  DoD  5000.2-R,  Section  C6.3.  Supportability  refers  to  the 
ability  of  existing  and  planned  IT,  including  NSS,  systems  and  infrastructure  components  to  aid, 
protect,  complement,  and  sustain  development  or  operation  of  the  system  being  acquired. 
Sufficiency  refers  to  the  extent  to  which  requirements  are  satisfied  and  the  necessary  support  is 
available.  The  C4ISP  includes: 

AP5 . 1 . 1 . 1 .  A  system  description; 

AP5.1.1.2.  Operational  employment  concept  and  emplo5mient  rates,  including  mission 
area-focused  operational,  systems,  and  technical  architecture  views; 

AP5. 1 .1.3.  C4ISR  support  requirements  derived  through  analysis  from  the  employment 
concept/rates,  architecture  views,  and  the  performance  capabilities  and  characteristics  specified 
by  the  Operational  Requirements  Document  (ORD)  or  equivalent  document  validated  by  the 
requirements  authority;  and 

AP5.1.1.4.  Potential  C4ISR  shortfalls  with  proposed  solutions  or  mitigation  strategies. 

AP5.1.2.  The  C4ISP  shall  describe  system  dependencies  and  interfaces  in  sufficient  detail 
to  enable  test  planning  for  interoperability  KTPs  and  lERs.  The  Joint  Staff  shall  provide 
supportability  (by  J-6)  and  intelligence  (by  J-2)  certification  of  C4ISPs  for  all  programs. 

APS. 1.3.  Each  DoD  Component  shall  establish  an  internal  C41SP  management  process  that 
supports  preparation  and  review  of  C4ISPs,  leading  to  C4ISP  approval  by  a  designated 
Component  official.  This  process  shall  include  coordination  with  all  affected  DoD  components. 
Comments  raised  during  C4ISP  review  shall  be  resolved  prior  to  approval.  Each  DoD 
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Component  shall  designate  a  principal  point  of  contact  (POC)  to  represent  the  Component  on 
C4ISP  policy  and  procedural  matters. 

APS.  1.4.  DoD  Components  shall  identify  C4ISR  information,  infrastructure,  and  other  IT, 
including  NSS,  interface  and  support  requirements  from  the  beginning  of  each  program’s  life 
cycle.  These  considerations  will  facilitate  preparation  of  the  analysis  of  alternatives,  and  help 
refine  operational  goals.  Concurrently  with  initial  ORD  preparation  and  validation,  the 
Component  shall  develop  a  C4ISP  that  identifies  the  C4ISR  support  and  IT,  including  NSS, 
capabilities  that  must  be  in  place  to  meet  the  proposed  operational  requirements  in  the  ORD  and 
to  satisfy  the  program's  planned  employment.  A  C4ISP  must  be  in  place  by  program  initiation. 
As  the  program  matures,  or  proceeds  through  multiple  evolutionary  blocks  or  phases,  the 
Component  shall  keep  the  C4ISP  current.  Updates  shall  contain  progressively  more  detailed  and 
specific  time-phased  descriptions  of  the  types  of  information  needed;  operational,  systems,  and 
technical  architecture  requirements;  information  exchange  requirements  (lERs);  spectrum 
supportability,  security,  connectivity,  and  interoperability  issues;  and  infrastructure,  intelligence, 
and  other  IT,  including  NSS,  support  shortfalls.  Changes  in  C4ISR  information,  infrastructure, 
and  other  IT,  including  NSS,  interface  requirements  that  result  from  proposed  changes  in  the 
approved  ORD  shall  be  highlighted  to  facilitate  review  and  evaluation. 

AP5.1.5.  DoD  Components  shall  tailor  C4ISPs  according  to  the  complexity,  scale,  mission 
criticality,  or  other  unique  aspects  of  the  system's  C4ISR  support  and  IT,  including  NSS, 
interface  requirements. 

AP5.2.  PREPARATION 

AP5.2.1.  Ideally,  a  working-level  integrated  product  team  (WIPT)  should  develop  the 
C4ISP.  The  WIPT  should  comprise  subject  matter  experts  familiar  with  the  system  being 
acquired,  the  intended  use  of  the  system,  and  to  the  extent  possible,  the  operational  and  system 
architectures  within  which  the  system  will  function.  As  the  operational  and  system  architectures 
mature,  the  WIPT  should  include  consultations  with  the  principal  systems  with  which  the  system 
being  acquired  will  interface.  Assessing  the  capabilities  of  interfacing  systems  to  satisfy  the 
program's  operational  and  derived  requirements  (Section  4  of  the  C4ISP)  will  require  continuing 
collaboration  among  subject  matter  experts  of  all  systems  involved. 

AP5.2.2.  The  Component  shall  allow  sufficient  time  to  prepare  and  update  the  C4ISP  so 
that  review  of  the  C4ISP  can  be  completed  before  an  upcoming  milestone  or  decision  review. 
Preparation  shall  include  careful  consideration  of  the  information,  infrastructure,  and  interface 
support  requirements  levied  by  and  on  the  program,  and  a  thorough  (and  iterative)  document 
review  process.  Managers  of  interfacing  programs  identified  in  the  C4ISP  should  review  the 
document  during  this  process  for  completeness,  and  validate  shortfalls  and  solutions  (Section  5 
of  the  C4ISP). 
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AP5.2.3.  Components  shall  prepare  the  C4ISP  at  the  classification  level  necessary  to 
completely  communicate  the  required  information,  without  unnecessary  reliance  on  reference 
dociunents  that  may  not  be  generally  available  to  users  or  reviewers.  Components  shall  not  keep 
a  C4ISP  imclassified  merely  to  facilitate  document  review;  however,  unclassified  C4ISPs  with 
classified  annexes  may  sometimes  be  appropriate.  Components  shall  consider  the  implications 
of  compiling  detailed,  sensitive  but  imclassified  information  and/or  proprietary  information  in  a 
document  that  receives  wide  distribution  during  review. 

AP5.2.4.  Before  a  C4ISP  is  distributed  for  review,  Components  shall  certify  that  all  satellite 
communications  requirements  of  the  acquisition  program  have  been  approved  for  inclusion  in  the 
SATCOM  Emerging  Requirements  Data  Base  in  accordance  with  CJCSI  6250.01. 

AP5.3.  COORDINATION 

DoD  Components  shall  manage  the  review  of  all  C4ISPs  within  their  Components,  and  shall 
obtain  supportability  and  intelligence  certifications  through  C4ISP  review  by  the  Joint  Staff. 
OASD(C3I)  shall  lead  a  DoD-wide  review  of:  (1)  C4ISPs  for  all  ACAT I  and  lA  (ID,  IC,  lAM, 
and  lAC)  acquisition  programs;  and  (2)  C4ISPs  for  other  acquisition  programs  in  which 
OASD(C3I)  has  indicated  a  special  interest.  The  Joint  Staff,  USJFCOM,  other  DoD 
Components,  and  USD(AT&L)  and  other  DoD  agencies  may  recommend  programs  for  the 
C4ISP  special  interest  list  (e.g.,  identification  of  non-standard  requirements  for  information,  or 
mismatch  of  time  critical  information  requirements  and  technical  capabilities).  Should 
interoperability  issues  arise  between  ACAT  I  or  lA  and  less-than-ACAT  I  or  lA  programs,  DoD 
Components  shall,  if  requested,  be  able  to  provide  the  C4ISP  for  the  less-than-ACAT  I  or  lA 
program(s)  to  the  ASD(C3I)  to  support  issue  resolution. 

AP5.3.1.  DoD-Wide  Reviews  led  by  OASD(C3I) 

APS. 3. 1.1.  When  a  system  interfaces  or  will  interface  with  systems  of  other  DoD 
Components  during  development,  testing,  training,  or  operation,  the  acquiring  Component  shall 
obtain  the  coordination  of  the  affected  Components  prior  to  submitting  the  C4ISP  for  DoD 
review. 


AP5.3.1.2.  DoD  review  of  C4ISPs  shall  precede  each  major  milestone,  beginning  at 
program  initiation,  and  other  decision  points  as  specifically  directed.  The  DoD  review  process 
will  be  accomplished  in  stages.  Stage  1  is  review  of  the  early  draft,  usually  beguming  no  later 
than  6  months  prior  to  milestone  review.  (Stage  1  review  may  go  through  several  drafts.)  Stage 
2  is  review  of  the  final  draft,  beginning  no  later  than  60  days  before  the  milestone.  Stage  3  is  the 
submission  of  the  Component-approved  C4ISP  with  the  relevant  acquisition  decision 
memorandum.  Stage  2  and  3  submissions  require  a  correlation/resolution  matrix  showing 
disposition  of  the  critical  and  substantive  comments  received  during  the  previous  stage. 
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AP5.3.1.3.  When  the  C4ISP  includes  requirements  resulting  from  update  of  the  ORD, 
DoD  review  normally  shall  not  begin  until  the  corresponding  stage  of  ORD  review  has  been 
completed.  That  is.  Stage  1  review  of  the  C4ISP  shall  follow  Stage  1  review  of  the  ORD,  and 
Stage  2  review  of  the  C4ISP  shall  follow  Stage  2  review  of  the  ORD. 

AP5.3.1.4.  Components  shall  submit  the  C4ISP  electronically  to  the  Director, 
OASD(C3I)  Program  Analysis  and  Integration  (PA&I).  They  shall  submit  unclassified  C4ISPs 
via  the  Joint  C4ISP  Assessment  Tool  (JCPAT)  NIPRNET  site.  They  shall  submit  classified 
C4ISPs,  through  SECRET,  via  the  JCPAT  SIPRNET  site.  The  OASD(C3I)  program  lead  or  the 
JCPAT  manager  at  DISA  shall  provide  specific  instructions,  including  recommended  document 
formats  to  facilitate  the  DoD  review  process.  The  OASD(C3I)  program  lead  shall  provide 
procedures  for  submitting  C4ISPs  above  the  level  of  SECRET.  Information  copies  of  both 
approved  and  draft  ORDs  shall  be  submitted  with  the  C4ISP  to  facilitate  the  review  process. 

AP5.3.2.  DoD  Review  Process. 

AP5.3.2.1.  A  broad  range  of  activities  review  the  C4ISP  and  use  it  as  a  vehicle  to 
conduct  a  variety  of  interoperability  and  supportability  assessments.  At  a  minimum,  the 
following  offices  review  the  C4ISP:  ASD(C3I),  Under  Secretary  of  Defense  (Acquisition, 
Technology  and  Logistics  (USD(AT&L)),  Director,  Operational  Test  and  Evaluation  (DOT&E), 
Joint  Staff  (J-2,  J-3,  J-6,  and  J-8),  MilDeps,  USJFCOM,  DISA,  and  NIMA. 

AP5.3.2.2.  After  administrative  evaluation  of  the  C4ISP  to  determine  its  readiness  for 
external  review,  the  OASD(C3I)  shall  release  the  document  for  review,  assessment,  and 
comment.  C4ISP  review  shall  occur  in  conjunction  with  supportability  and  intelligence 
certification  by  the  Joint  Staff  CJCSI  3170.01B,  CJCSI  3312.01,  and  CJCSI  6212.01B  address 
Joint  Staff  review  and  certification  procedures. 

AP5.3.2.3.  GS-15/0-6  division  chief-level  executives  shall  conduct  the  Stage  1  review. 
For  Stage  1  review,  the  suspense  date  for  comments  to  OASD(C3I)  shall  normally  be  35  days 
from  the  date  of  the  JCPAT  distribution  notice.  Senior  Executive  Service/flag-level  executives 
shall  conduct  the  Stage  2  review  for  ACAT  I  programs;  GS-15/0-6  division  chief-level 
executives  shall  conduct  Stage  2  reviews  for  non-ACAT  I  programs.  Stage  2  shall  include  final 
supportability  and  intelligence  certifications  by  the  Joint  Staff  For  Stage  2  review,  the  suspense 
date  for  comments  to  the  OASD(C3I)  shall  normally  be  21  days  from  the  date  of  the  JCPAT 
distribution  notice.  Comments  shall  reflect  the  position  of  the  responding  CINC,  MilDep,  OSD 
Directorate,  Joint  Staff  Directorate,  or  Agency. 

AP5.3.2.4.  In  addition  to  review  of  individual  C4ISPs,  the  OASD(C3I)  shall  extract 
information  from  the  C4ISP  and  other  sources  to  facilitate  identification  and  resolution  of  cross- 
program  C4ISR  infrastructure  and  support  issues.  This  includes  shortfalls  identified  in  C4ISPs 
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or  through  the  C4ISP  review  process.  The  OASD(C3I)  shall  raise  significant  program-specific 
issues  identified  diiring  this  process  with  the  Component  preparing  the  C4ISP. 

AP5.3.3.  Shortfall  Identification  and  Resolution. 

APS. 3 .3.1.  Derived  requirements  are  interoperability  or  support  needs  that  are 
identified  during  C4ISP  development.  Derived  requirements  that  cannot  be  satisfied  constitute 
shortfalls.  The  C4ISP  review  process  can  also  identify  shortfalls.  The  C4ISP  shall  document  all 
shortfalls,  plans  and  schedules  for  their  resolution,  and  strategies  for  mitigating  the  shortfalls 
imtil  each  is  resolved.  The  acquisition  strategy  shall  summarize  shortfalls  (see  DoD  5000.2-R, 
Section  2.7.3). 

AP5.3.3.2.  When  a  shortfall  is  identified,  the  Component  shall  determine  whether  or 
not  the  shortfall  constitutes  a  new  mission  need.  If  so,  the  Component  shall  submit  the  mission 
need  into  the  requirements  generation  system  in  accordance  with  CJCSI  3170.01B.  All  shortfalls 
should  be  resolved  at  the  lowest  possible  level.  Shortfalls  that  cannot  be  resolved  at  the  program 
office  level  should  be  addressed  in  accordance  with  DoD  5000.2-R,  Part  7. 

AP5.3.4.  Feedback.  The  OASD(C3I)  shall  consolidate  comments  from  each  stage  of  the 
review,  and  provide  official  feedback  to  the  Component  preparing  the  C4ISP.  Feedback  shall 
include  identification  of  critical  interoperability  and  supportability  issues  that  must  be  addressed 
during  the  program’s  milestone  review  process.  Critical  issues  must  be  resolved  either  prior  to 
the  milestone  or  decision  review,  or  through  tasking  in  the  Acquisition  Decision  Memorandum. 
The  OASD(C3I)  shall  return  formal  comments  as  an  attachment  under  a  standard  cover  letter 
providing  an  overall  assessment  of  the  C4ISP,  a  statement  as  to  whether  there  are  any  “critical” 
issues,  and  a  statement  concerning  the  program’s  readiness  for  a  milestone  decision  from  the 
standpoint  of  C4ISR  supportability  and  IT,  including  NSS,  interoperability.  This  letter  will  also 
forward  any  unresolved  Stage  2  “critical”  issues  to  the  Overarching  Integrated  Product  Team 
(OIPT),  MDA,  and  program  manager  for  consideration  as  part  of  the  milestone  or  decision 
review. 

AP5.3.5.  C4ISP  Completion.  The  objective  of  all  participants  is  to  complete  the  Stage  2 
review  prior  to  the  milestone  or  decision  review  so  that  the  MDA  can  address  and  resolve 
outstanding  critical  concerns  raised  during  C4ISP  coordination.  However,  C4ISP  review  status 
shall  not  by  itself  delay  a  program  milestone  review.  The  MDA  shall  address  critical,  open 
C4ISP  issues  even  after  milestone  approval. 

AP5.3.6.  Approval  of  C4ISPs.  Following  satisfactory  resolution  of  outstanding  issues,  the 
official  designated  by  the  Component  shall  approve  the  C4ISP.  Copies  of  all  approved  C4ISPs 
shall  be  submitted  electronically  to  the  Director,  OASD(C3I)  Program  Analysis  and  Integration 
(PA&I),  with  the  relevant  Acquisition  Decision  Memorandum.  This  includes  both  approved 
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C4ISPs  that  have  undergone  DoD-wide  review  led  by  OASD(C3I),  and  approved  C4ISPs 
reviewed  in  accordance  with  Component  procedures. 

APS.4.  DOCUMENTATION  INTERFACES 


AP5.4.1.  The  C4ISP  documents  the  C4ISR  and  IT,  including  NSS,  support  needed  to 
respond  to  a  CRD  (if  applicable)  and  an  ORD  by  describing  and  evaluating  the  C4ISR 
information,  infrastructure,  and  other  IT,  including  NSS,  interfaces  that  the  acquisition  program 
needs  during  development,  testing,  training,  and  operation.  If  the  ORD  is  updated,  the 
Component  shall  update  the  C4ISP  accordingly. 

AP5.4.2.  The  acquisition  strategy  addresses  major  C4ISR  and  IT,  including  NSS,  support 
considerations  for  the  acquisition  program.  This  includes  major  information  and  C4ISR 
infrastructure  enhancements  critical  to  program  success.  This  information  is  a  summary  of  the 
details  documented  in  the  C4ISP. 

AP5.4.3.  The  Test  and  Evaluation  Master  Plan  (TEMP)  addresses  key  system  interfaces  and 
measurable  test  parameters.  The  TEMP  documents  the  overall  structure  and  objectives  of  the 
tests  that  will  be  performed  to  evaluate  system  interoperability  and  C4ISR  supportability.  This 
includes  interoperability  KPPs  and  lERs  from  the  associated  ORD,  plus  the  IT,  including  NSS, 
interfaces  and  lERs  specified  in  the  C4ISP.  The  C4ISP  also  identifies  C4ISR  support  that  must 
be  provided  to  execute  the  TEMP. 

AP5.5.  MANDATORY  FORMAT 

APS. 5. 1 .  The  mandatory  C4ISP  format  begins  on  the  next  page.  Note:  The  Defense 
Acquisition  Deskbook  and  the  C4ISR  Architecture  Framework  (renamed  the  DoD  Architecture 
Framework  in  versions  2.1  and  later)  contain  additional  guidance  for  preparing  the  C4ISP  and 
the  selected  architecture  products  (OV-1,  OV-2,  OV-3,  OV-6c,  SV-1,  SV-6,  and  TV-1)  that  are 
required  for  the  C4ISP. 

AP5.5.2.  The  level  of  detail  in  a  C4ISP  will  increase  as  an  acquisition  program  proceeds 
from  program  initiation  to  Milestone  C,  and  to  follow-on  blocks  of  an  evolutionary  acquisition. 
At  program  initiation,  a  C4ISP  is  not  expected  to  contain  all  of  the  information  about  initial 
operating  capabilities  or  future  system  interfaces  that  will  be  available  at  Milestone  C  or  at  the 
full-rate  production  decision  point.  Requirements,  employment  concepts,  and  architectures  for 
both  the  system  being  acquired,  and  the  systems  with  which  it  interfaces,  will  evolve  and  mature 
throughout  the  acquisition  life  cycle.  A  C4ISP  is  an  analysis  of  requirements  and  planned 
solutions  as  of  the  current  point  in  time.  In  preparing  and  maintaining  a  C4ISP,  the  Component 
is  responsible  for  identifying  what  relevant  interoperability,  supportability,  and  sufficiency 
information  is  unknown,  or  which  cannot  reasonably  be  predicted,  about  the  future  environment 
within  which  the  system  will  function.  Likewise,  a  C4ISP  is  not  expected  to  address  all  possible 
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contingencies.  Rather,  it  should  identify  representative  qualitative  and  quantitative  information 
about  likely  scenarios  and  operating  conditions,  identifying  to  the  extent  possible  where  such 
generalizations  introduce  risk. 
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C4I  SUPPORT  PLAN 
FOR 

PROGRAM  TITLE 


1 .  Introduction:  Provide  a  high-level  system  description  and  discussion  of  C4ISP 
contents.  Identify  the  program,  acquisition  category,  and  status  within  the  acquisition  cycle; 
state  the  purpose  and  scope  of  the  C4ISP;  and  reference  all  approved  (or  validated)  and  draft 
docximents  affecting  the  C4ISR  and  IT,  including  NSS,  aspects  of  the  system  that  is  being 
acquired.  Provide  extensive  references  in  Appendix  A  rather  than  in  the  body  of  the  C4ISP. 
Identify  points  of  contact  for  further  discussion. 

2.  System  Description:  Provide  a  high-level  overview  of  the  specific  system  being 
acquired.  Provide  a  graphic  (block  diagram)  that  shows  the  major  elements/subsystems  that 
make  up  the  system  being  acquired,  and  how  they  fit  together.  For  a  weapon  system,  describe 
the  purpose,  design  objectives,  warhead  characteristics,  sensors,  guidance  and  control 
capabilities  and  limitations  (if  appropriate),  command  and  control  environment,  general 
performance  envelope,  and  primary  IT,  including  NSS,  interfaces.  For  a  command  and  control 
system,  describe  the  system’s  function  and  interfaces  with  other  IT,  including  NSS,  systems.  For 
an  automated  information  system  (AIS),  describe  the  system’s  function,  its  mission 
criticality/essentiality,  interfaces  with  other  IT,  including  NSS,  systems,  and  primary  databases 
supported. 

3.  Operational  Employment :  Describe  how  the  system  being  acquired  will  be  employed, 
and  the  environment  within  which  it  will  operate.  Address  all  information  interfaces,  exchange 
requirements,  and  IT,  including  NSS,  capabilities  required  to  comply  with  the  ORD,  as  well  as 
other  information  interfaces  and  exchange  requirements  necessary  to  execute  the  concept  of 
operation  for  the  system  at  IOC  and  at  subsequent  major  events,  such  as  block  upgrades  or 
deployment  of  other  key  systems.  A  strategy-to-task  (STT)  methodology  is  the  preferred 
approach  for  defining  operational  and  system  architecture  views,  as  well  as  for  determining 
derived  requirements  (Section  4).  The  STT  framework  links  means  and  ends  through  a  hierarchy 
of  objectives.  It  provides  an  au^t  trail  from  broad  objectives  down  to  operational  and  tactical 
concepts  where  elements  are  linked  together  using  weapons,  platforms,  other  IT,  including  NSS, 
and  tactics  to  achieve  the  objectives. 

3.1  Operational  Employment  Concept:  Define  the  system’s  operational  concept  on  a 
mission  area  basis  (or  functional  area  basis  for  AISs).  The  operational  concepts  described  should 
be  based  on  Joint  Guidance  and  on  operational  procediures  pertaining  to  the  system,  and  should 
show  how  the  operational  concept  changes  over  time,  if  applicable.  Clearly  relate  missions 
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performed  to  the  joint  mission  areas  specified  in  CJCS  memorandum  CM-1014-00,  "Joint 
Mission  Areas  to  Organize  the  Joint  Operational  Architecture”  dated  September  6,  2000. 
Describe  the  electromagnetic  environment  within  which  the  system  will  operate.  Identify  system 
functions  that  are  critical  for  specific  missions. 

Describe  at  a  high  level,  the  operational  environment(s)  within  which  the  system  will 
operate.  This  includes  the  types  and  characteristics  of  Service,  joint,  and  combined  forces  likely 
to  be  employed,  the  electromagnetic  environment,  spectrum  supportability  requirements,  and 
other  factors  that  might  constrain  operations,  and  the  availability  of  support  functions/capabilities 
on  which  the  system  must  rely  for  effective  operation. 

3.1.1  Operational  Architecture  Views :  Provide  a  High  Level  Operational  Concept 
Graphic  (OV-1)  for  each  mission  area  supported  by  the  system.  Similar  missions  may  be 
covered  in  a  single  OV-1.  For  each  OV-1,  provide  supporting  text  that  describes  the  capabilities 
and  functions  of  each  node  and  interface,  identifying  &ose  that  are  critical  to  success  of  the 
mission  as  depicted  in  Section  3.  The  OV-1  architecture  view(s)  must  correlate  with  the  OV-1 
view(s)  from  the  associated  ORD.  For  each  mission  (or  functional)  area  supported  by  the 
system,  provide  an  Operational  Node  Connectivity  Description  (OV-2)  that  shows  the  intra- 
Service,  inter-Service/joint,  and  combined/coalition  C4ISR  support  and  IT,  including  NSS, 
interfaces  associated  with  that  mission  or  function.  For  each  OV-2,  provide  supporting  text  that 
describes  the  roles  of  each  operational  facility  (OPFAC)  node  in  the  architecture,  including  the 
functions  that  each  OPFAC  performs  that  are  critical  to  the  success  of  the  mission.  Provide 
multiple  OV-1  and  OV-2  graphics  if  necessary  because  of  operational  concept  changes  over 
time. 

3.1.2  Information  Exchange  Requirements  (lERs):  The  lines  connecting  the  nodes  in 
the  OV-2  represent  information  exchange  needs,  which  encompass  one  or  more  lERs.  Provide 
an  OV-3  (Operational  Information  Exchange  Matrix)  operational  architecture  view  that  is  cross- 
referenced  to  the  OV-2  views,  showing  all  individual  lERs  represented  by  the  need  lines.  The 
lERs  from  the  associated  ORD  will  be  a  subset  of  the  lERs  in  die  C4ISP.  All  C4ISR  support  and 
IT,  including  NSS,  lERs  that  are  necessary  for  successful  performance  of  the  mission  must  be 
represented  in  the  OV-2  and  OV-3  views,  whether  or  not  they  are  identified  as  "critical"  lERs. 
This  includes  intra-Service,  inter-Service/joint,  and  combined/coalition  information  exchange 
requirements.  Describe  the  interoperability  key  performance  parameter  (KPP),  and  show  the 
construction  of  threshold  and  objective  values,  with  supporting  explanation  of  lER  criticality. 

The  lERs  should  include  all  required  fields  specified  in  CJCSI  62 12.0 IB  for  ORD  lERs, 
plus  the  fields  that  are  needed  to  specify  attributes  that  are  necessary  for  supportability 
assessment  (see  Section  3.4  on  system  lER  matrix  requirements).  Large  lER  matrices  and 
detailed  supporting  narrative  should  be  included  in  Appendix  B,  rather  than  in  the  body  of  the 
C4ISP.  Provide  a  copy  of  the  OV-3  matrix  as  a  separate,  appended  spreadsheet  file. 

3.2  Operational  Employment  Requirements :  Identify  the  impact  of  the  information 
exchanges  and  information  needs  on  the  supporting  infrastructure  and  ISR  systems,  and  on  other 
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IT,  including  NSS,  interfaces  that  are  critical  to  mission  success.  Where  possible,  this 
information  should  be  based  on  modeling  of  Operational  Situations  (OPSITs)  within  which  the 
system  will  perform.  Since  it  is  impractical  to  model  all  possible  situations,  a  high  tempo 
situation  such  as  a  major  theater  war  and  a  low  tempo  situation  such  as  a  Noncombatant 
Evacuation  Operation  (NEO)  should  be  used.  Where  formal  modeling  has  not  been  done,  the 
best  available  information  on  likely  and  peak  employment  rates  (communications  load  and 
throughput)  should  be  used  in  its  place.  Discuss  the  threat  and  tactical  considerations,  describe 
time-critical  events  required  to  meet  operational  objectives,  and  address  workload  considerations 
based  on  the  operational  employment  concept.  Include  Operational  Event/Trace  Description 
(OV-6c)  views  when  needed  to  clarify  the  time-critical  nature  of  information  for  each  mission. 

3.3  Systems  Architecture  View:  Provide  time-phased,  mission-based  graphical  and 
narrative  descriptions  of  current/future  systems  and  connectivity  providing,  receiving,  or 
supporting  the  functions  of  the  system  being  acquired.  For  each  mission  or  mission  area 
described  in  Section  3.1,  show  the  systems  that  are  anticipated  to  fulfill  the  needs.  For  each 
mission  area  operational  view  (OV-2)  described  in  section  3.1,  there  must  be  a  corresponding 
System  Interface  Description  (SV-1)  view.  Each  notional  OPFAC  should  be  replaced  by  either 
an  existing  or  a  planned  system  or  facility,  and  each  need  line  should  represent  a  particular 
communication  system  that  will  provide  a  path  for  the  information  exchange.  The  SV-1 
architecture  view(s)  must  correlate  with  the  SV-1  view(s)  from  the  associated  ORD. 

Provide  increasing  detail  as  the  acquisition  progresses  from  milestone  to  milestone  and 
from  evolutionary  block  to  block.  At  a  minimum,  include  existing  or  planned  systems  and 
networks  that;  (1)  Provide  input  to,  or  receive  output  from,  the  system  being  acquired;  (2) 
Support  primary  activities  related  to  the  system;  and  (3)  Support  nodes  where  interfacing 
systems  are  located.  Describe  the  relevant  information  exchange  capabilities,  operation,  and 
limitations  of  each  system  within  the  architecture.  Identify  key  nodes  for  information  exchanges 
including  materiel  equipment,  physical  connections,  association  of  systems  to  nodes,  circuits, 
networks,  warfighting  platforms,  and  relevant  specific  system  and  component  performance 
parameters  such  as  reliability/maintainability  and  availability. 

3.4  Systems  lER  Matrix  Information:  A  systems  lER  matrix  enhances  the  information 
flows  dociimented  in  the  OV-3,  and  includes  systems  and  communications  information  for  each 
need  line  in  the  SV-1.  Append  the  information  required  by  an  SV-6  systems  lER  matrix  to  each 
row  of  the  OV-3  operational  lER  matrix  (Section  3.1.2).  Include  details  and  any  extensive 
supporting  discussion  in  Appendix  B. 

3.5  Technical  Architecture:  Identify  applicable  technical  standard(s)  for  each  lER,  based 
upon  the  DoD  Joint  Technical  Architecture  (JTA).  Include  a  discussion  of  relevant 
interoperability  considerations,  addressing  operations  with  joint  and  combined  forces  in 
particular.  Discuss  how  the  standards  are  or  will  be  implemented,  and  identify  applicable 
existing  technical  guidance  and  tailoring.  Provide  a  Technical  Architecture  View  (TV-1)  that 
identifies  the  applicable  standard(s)  for  each  row  of  the  OV-3  operational  lER  matrix  (Section 
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3.1.2).  Large  TV-1  matrices  and  detailed  supporting  narrative  should  be  included  in  Appendix 
C,  rather  than  in  the  body  of  the  C4ISP. 

3.6  Defense-Wide  Integrated  Architectures:  Provide  a  qualitative  assessment  of  the  extent 
to  which  the  time-phased  operational,  systems,  and  technical  architecture  views  in  Section  3.1 
through  Section  3.5  are  consistent  with  the  evolving  Global  Information  Grid  (GIG)  integrated 
architecture  (including  the  joint  operational  and  technical  architectures),  and  with  relevant 
mission  area  integrated  architectures,  as  of  the  point  in  time  at  which  the  C4ISP  is  prepared. 
Highlight  and  characterize  significant  differences,  regardless  of  whether  they  result  fi'om:  (1) 
Incomplete  or  imperfect  Defense- wide  or  mission  area  architectures;  (2)  Validated  program 
requirements,  employment  concepts,  or  system  development  decisions  that  cannot  be  changed 
without  a  major  program  impact;  or  (3)  Current  differences  that  the  DoD  Component  plans  to 
resolve  later  in  the  system's  acquisition  life  cycle.  Describe  the  interoperability,  supportability, 
or  sufficiency  impact  of  these  differences,  and  also  summarize  them  in  Section  5. 

4.  Derived  C4I  Support  Requirements:  Document  the  derived  C4ISR  support  and  IT, 
including  NSS,  capabilities  required  to  satisfy  the  development,  testing,  training,  and  operational 
emplo5Tnent  of  the  system.  Section  4  should  be  organized  by  the  function  performed  (or 
mission,  or  organization,  as  appropriate)  and  the  system  that  provides  information  to,  or  receives 
information  from,  the  system  being  acquired.  Section  4  is  not  a  restatement  of  the  basic 
operational  requirements  contained  in  the  ORD.  Rather,  it  is  the  result  of  a  formal  analysis  that 
derives  the  C4ISR  support  and  IT,  including  NSS,  that  must  be  in  place  to  meet  the  operational 
requirements  in  the  ORD  when  the  system  is  employed  as  described  in  Section  3  of  the  C4ISP . 
Focus  on  the  C4  (including  IT  and  NSS)  and  ISR  support  requirements  necessary  for  the  system 
to  be  successfully  developed  and  to  perform  its  intended  function,  both  as  a  consumer  and  as  a 
producer/distributor  of  information.  This  includes  requirements  that  must  be  satisfied  by 
organizations  or  programs  in  other  DoD  Components,  as  well  as  requirements  that  must  be 
satisfied  by  the  program  office  for  the  system  being  acquired  and  by  other  organizations  or 
programs  throughout  the  DoD  Component  preparing  and  submitting  the  C4ISP. 

The  Strategy-to-Task  (STT)  methodology  recommended  in  Section  3  is  the  preferred 
approach  for  identifying  these  derived  requirements  through  hierarchical  decomposition  of  the 
operational  tasks  performed  by  the  system  being  developed.  This  analysis  process  may  identify 
requirements  that  must  be  addressed  through  update  of  the  ORD  for  either  the  system  being 
acquired  or  another  information  consumer/producer  system,  or  through  development  of  a  new 
Mission  Needs  Statement  (MNS). 

4.1  C4ISR  Support  to  Operations:  Couple  each  employment  concept  (Section  3.1)  with 
the  corresponding  employment  rates  (Section  3.2)  and  the  system  architectures  (Sections  3.3)  to 
assess  and  characterize  the  requirements  placed  on  C4ISR  support  systems  and  IT,  including 
NSS,  activities. 

4.1.1  C4  (including  IT  and  NSS)  Support  to  Operations:  Describe  the  support  required 
from  the  C4  infrastructure  and  other  IT,  including  NSS,  (e.g.,  other  weapon  systems)  by  the 
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system  being  acquired.  Each  sub-section  should  show  the  demands  of  the  system  being  acquired 
on  the  particular  supporting/interfacing  C4  system  for  each  mission.  Provide  the  following 
information  for  each  external  system  interface:  organizations  or  activities  involved;  networks  or 
other  means  used  to  exchange  information;  transmission  types  (e.g.,  satellite  commimications 
(SATCOM)  relay,  landline,  line-of-sight  communications);  other  communication  requirements 
(e.g.,  spectrum  supportability  requirements  such  as  frequencies  and  bandwidth,  certification 
status,  supportability  constraints  or  conflicts,  and  host  nation  authorization);  sending/receiving 
databases  and  software,  mission  criticality. 

Identify  the  primary  IT,  including  NSS,  capabilities  of  each  system,  including  computer 
hardware/soflware,  workstations,  peripherals,  central  processors,  and  routing  processors.  Include 
relevant  options  such  as  scalability,  operating  system  or  software  characteristics,  etc.  Identify 
new  or  updated  data  that  may  be  required  by  the  system.  Identify  data  rates  under  a  range  of 
operating  conditions.  Identify  the  information  security  classification  level(s)  required  and 
capabilities  employed.  For  example,  if  data  is  encrypted,  identify  the  type  of  encryption  planned. 

Address  information  assurance,  infrastructure  assurance,  and  protection  of  critical  systems 
and  infrastructures,  giving  special  consideration  to  vulnerabilities  resulting  from  reliance  on 
other  government  or  civil  sector  infrastructures  and  the  risk  of  their  loss,  damage  or  destruction. 
The  goal  is  to  reduce  risks  imposed  by  those  vulnerabilities  and  interdependencies  during 
development. 

4.1.2  ISR  Support  to  Operations:  Describe  support  required  from  ISR  systems  by  the 
system  being  acquired.  Each  sub-section  should  show  the  support  required  from  each  supporting 
ISR  system,  together  with  the  attributes  this  support  must  possess  in  order  to  satisfy  the  needs  of 
the  system  being  acquired.  Address  the  full  range  of  ISR  support  systems  and  information 
exchange  requirements,  including  delivery  platforms;  intelligence  tasking,  collection,  processing, 
exploitation,  analysis,  production,  and  dissemination  activities  and  assets  (such  as  personnel  and 
facilities).  Assess  the  qualitative  and  quantitative  adequacy  of  supporting  systems  and  activities. 
Include  specific  types  and  elements  of  information,  and  their  associated  characteristics  and 
attributes  such  as  accuracy,  timeliness,  estimated  volume,  and  required  update  rates.  For  systems 
with  ISR  and  geospatial  information  needs,  address  the  area  of  coverage,  timeliness,  security, 
impact,  quantity,  quality,  assuredness,  robustness,  flexibility,  and  scalability.  The  level  of  detail 
used  in  describing  the  operational  support  requirements  should  be  sufficient  to  assess 
supportability. 

4.2  C4ISR  Support  to  Other  Functions:  Describe  any  special  C4ISR  support  that  is 
required  for  acquisition  or  sustainment  of  the  system. 

4.2.1  C4ISR  Support  to  Development:  Describe  any  special  C4ISR  support  that  is 
required  for  the  successful  development  of  the  system  being  acquired.  The  supporting  systems 
should  be  identified  with  the  nature  of  the  support  they  provide  clearly  shown. 

4.2.2  C4ISR  Support  to  Testing:  Describe  the  plan  to  provide  C4ISR  support  for  the 
system’s  developmental  and  operational  test  and  evaluation,  including  testing  of  lERs  and  the 
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interoperability  KPP.  (Plans  for  conducting  tests  of  the  IT,  including  NSS,  capabilities  of  the 
system,  including  end-to-end  testing,  joint/combined  interoperability  certification  testing,  and 
testing  of  lERs/KPPs,  are  addressed  in  the  TEMP.)  Address  required  support  for  interoperability 
demonstrations  and  testing  both  within  the  DoD  Component  (internal  testing),  and  by  external 
activities  such  as  the  Joint  Interoperability  Test  Command  (JITC).  Identify  all  information  and 
C4ISR  infrastructure  and  IT,  including  NSS,  capabilities  necessary  for  realistic  test  and 
evaluation.  If  the  testing  scheme  proposes  simulating  one  or  more  support  systems,  identify  the 
related  performance  parameters. 

4.2.3  C4ISR  Support  to  Training:  Identify  the  C4ISR  infrastmcture  and  IT,  including 
NSS,  required  to  support  training  activities  both  prior  to  and  after  IOC.  Discuss  anticipated  C4I 
support  to  training  required  for  each  of  the  three  mutually  supporting  pillars  of  training:  umt, 
institution,  and  self-development.  Identify  anticipated  operator,  crew,  and  netted  training  that 
may  be  required  to  support  joint  or  combined  operations.  Identify  anticipated  use  of  computer- 
based  training  modules,  simulations,  and  major  exercises. 

5.  Potential  C4I  Support  Shortfalls  and  Proposed  Solutions :  Address  known  or  potential 
shortfalls  in  required  C4ISR  support  capabilities;  shortfalls  in  manpower,  training,  or  doctrine  for 
C4ISR;  and  any  other  C4ISR  or  IT,  including  NSS,  limitations  that  may  reduce  the  operational 
effectiveness  of  the  system,  or  impede  its  development,  testing,  or  training.  Shortfalls  identified 
in  Section  5  must  be  supported  by  the  analysis  in  Section  4.  Include  all  derived  C4ISR  support 
requirements  (Section  4)  that  may  not  be  satisfied  by  the  date  that  they  are  needed.  This  includes 
C4ISR  support  requirements  that  may  not  be  satisfied  for  either  technical,  schedule,  or  funding 
reasons;  however,  there  is  no  requirement  to  quantify  funding  shortfalls  unless  the  mformation  is 
readily  available.  Include  C4ISR-related  shortfalls  of  other  interfacing  systems  as  well  as 
shortfalls  in  the  C4ISR  infrastructure.  Include  potential  shortfalls  that  are  reasonably  anticipated 
to  exist,  even  though  analysis  is  incomplete. 

Shortfalls  should  be  summarized  in  matrix  format,  organized  by  the  supporting/interfacing 
system  causing  or  affected  by  the  shortfall.  Each  row  of  the  matrix  should  identify  the  system, 
the  shortfall,  the  impact  of  the  shortfall  on  the  applicable  phase(s)  of  the  system  Hfe  cycle,  and 
the  proposed  solution  and/or  mitigation  strategy.  Provide  supporting  discussion  for  each  row  of 
the  matrix.  Specify  the  impact  of  failure  to  resolve  the  shortfalls  in  terms  of  program  resources 
and  schedule,  inability  to  achieve  threshold  performance,  and  system  or  war  fighter  vulnerability. 
Address  the  system’s  reliance  on  IT,  including  NSS,  technology  not  currently  available  or 
affordable,  and  the  system's  reliance  on  other  systems  under  development,  or  its  dependency  on 
schedules  of  other  programs.  Identify  the  plan  and  schedule  to  remedy  each  shortfall,  including 
key  issues  that  must  be  resolved.  If  the  solution  to  an  identified  shortfall  lies  outside  the  control 
of  the  program  office,  provide  a  recommendation  identifying  the  organization  with  the 
responsibility  and  authority  to  address  the  shortfall. 

5.1  Operational  Employment  Shortfalls:  Identify  known  or  potential  C4ISR  shortfalls  that 
will  affect  the  ability  to  employ  the  system  as  envisioned  by  the  ORD  and  employment  concept. 
Address  both  the  inability  of  the  C4ISR  infrastructure  to  meet  quantitative  or  qualitative 
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requirements,  and  the  inability  of  IT,  including  NSS,  interfaces  to  provide  or  receive  information 
as  intended.  Identify  interface  dependencies  that  remain  undefined  or  unsatisfied,  especially 
those  beyond  program  office  control.  Note  potential  conflicting  demands  on  infrastructure 
support  from  other  systems  and  activities. 

5.2  Other  Shortfalls:  Identify  known  or  potential  C4ISR  shortfalls  that  impact  other 
system  acquisition  and  sustainment  functions. 

5.2. 1  Development  Support  Shortfalls:  Identify  known  or  potential  C4ISR  shortfalls 
that  impact  definition  and  development  of  the  system  being  acquired.  Focus  particularly  on  ISR 
related  support  needed  to  define  the  system.  Include  shortfalls  that  limit  or  preclude  design 
tradeoff  studies  or  other  analyses  during  system  development  and  demonstration. 

5.2.2  Testing  Support  Shortfalls:  Identify  known  or  potential  C4ISR  shortfalls  that 
impact  developmental  or  operational  testing  of  the  system.  Focus  particularly  on  potential 
discontinuities  between  the  testing  plan  and  C4ISR  support  system  and  activity  availability. 

5.2.3  Training  Support  Shortfalls:  Identify  known  or  potential  C4ISR  shortfalls  that 
impact  the  proposed  training  schemes  for  both  system  development  and  test,  and  operational 
employment. 


Appendix  A.  References:  Identify  all  related  documents  (with  dates)  used  to  prepare  the 
C4ISP.  Include  all  essential  and  any  supporting  products  addressing  operational,  systems,  or 
technical  architecture  views  such  as  the  System  Threat  Assessment,  AoA,  MNS,  CRD,  ORD, 
TEMP,  System  Acquisition  Master  Plan  (SAMP),  acquisition  strategy.  Acquisition  Program 
Baseline  (APB),  C4I  Support  Plans  for  other  systems,  or  any  other  C4ISR  Architecture 
Framework  (renamed  the  DoD  Architecture  Framework  in  versions  2.1  and  later)  products. 
Except  for  the  current  approved  and  draft  ORD(s),  do  not  include  copies  of  the  reference 
documents.  Indicate  sources  for  any  documents  that  are  not  available  electronically  from  the 
program  office. 

Appendix  B.  Information  Exchange  Requirements  (lERs):  Provide  the  set  of  lERs  (and 
supporting  discussion)  for  each  operational  and  system  interface,  unless  this  information  is 
incorporated  in  Section  3.1.2  and  Section  3.4  of  the  C4ISP.  Appendix  B  will  consist  of  an  OV-3 
matrix  and  an  SV-6  matrix,  with  narrative  discussion  as  necessary.  Provide  a  copy  of  the  OV-3 
matrix  and  the  SV-6  matrix  as  separate,  appended  spreadsheet  files. 

Appendix  C.  Technical  Standards:  Provide  the  TV-1  matrix  (and  supporting  discussion), 
with  each  row  cross-referenced  to  the  applicable  row  of  the  OV-3  matrix,  unless  this  information 
is  incorporated  in  Section  3.5  of  the  C4ISP. 

Appendix  D.  Interface  Control  Agreements :  Identify  documentation  that  indicates  what 
agreements  have  been  made  (and  those  that  are  required  to  be  made)  between  dependent 
programs  for  C4ISR  support.  For  example,  if  system  A  is  relying  on  information  from  system  B, 
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then  this  interface  dependency  must  be  documented.  At  a  minimum,  this  dependency  should  be 
identified  in  the  C4I  Support  Plans  for  both  system  A  (the  information  recipient)  and  system  B 
(the  information  provider). 

Appendix  E.  Acronym  List:  As  appropriate,  also  provide  formal  definitions  for  key  terms. 
This  appendix  is  not  required  to  be  in  the  form  of  an  AV-2  Integrated  Dictionary. 

Other  Appendices  or  Aimexes.  As  required  to  provide  supporting  information  not  included  in 
the  body  of  the  C4ISP.  Additional  information  to  satisfy  Component-specific  requirements 
(such  as  cost  projections,  or  additional  C4ISR  Architecture  Framework  (renamed  the  DOD 
Architecture  Framework  in  versions  2. 1  and  later))  products  should  be  included  in 
appendices/annexes  or  as  separate  documents,  and  should  not  be  included  in  the  body  of  the 
C4ISP. 
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AP6.  APPENDIX  6 

TECHNOLOGY  READINESS  LEVELS  AND  THEIR  DEFINITIONS 


AP6.1.  TECHNOLOGY  READINESS  LEVELS 


The  following  matrix  lists  the  various  technology  readiness  levels  and  provides  a  description  of 
each. 


Technology  Readiness  Level 

Description 

1.  Basic  principles  observed  and  reported. 

Lowest  level  of  technology  readiness.  Scientific 
research  begins  to  be  translated  into 
techno  fogy’s  basic  properties. 

2.  Technology  concept  and/or  application 
formulated. 

Invention  begins.  Once  basic  principles  are 
observed,  practical  applications  can  be  invented. 
The  application  is  speculative  and  there  is  no 
proof  or  detailed  analysis  to  support  the 
assun5)tion.  Examples  are  still  limited  to  paper 
studies. 

3.  Anal)^ical  and  experimental  critical  ftmction 
and/or  characteristic  proof  of  concept. 

Active  research  and  development  is  initiated. 

This  includes  analytical  studies  and  laboratory 
studies  to  physically  validate  analytical 
predictions  of  separate  elements  of  the 
technology.  Examples  include  components  that 
are  not  yet  integrated  or  representative. 

4.  Component  and/or  breadboard  validation  in 
laboratory  environment. 

Basic  technological  components  are  integrated 
to  establish  that  the  pieces  will  work  together. 

This  is  relatively  “low  fidelity”  compared  to  the 
eventual  system.  Examples  include  integration 
of  “ad  hoc”  hardware  in  a  laboratory. 

5.  Component  and/or  breadboard  validation  in 
relevant  environment. 

Fidelity  of  breadboard  technology  increases 
significantly.  The  basic  technological 
components  are  integrated  with  reasonably 
realistic  supporting  elements  so  that  the 
technology  can  be  tested  in  simulated 
environment.  Examples  include  “high  fidelity” 
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laboratory  integration  of  components. 

6.  System/subsystem  model  or  prototype  Representative  model  or  prototype  system, 

demonstration  in  a  relevant  environment.  which  is  well  beyond  the  breadboard  tested  for 

level  5,  is  tested  in  a  relevant  environment. 
Represents  a  major  step  up  in  a  technology’s 
demonstrated  readiness.  Examples  include 
testing  a  prototype  in  a  high  fidelity  laboratory 
environment  or  in  simulated  operational 
environment. 

7.  System  prototype  demonstration  in  an  Prototype  near  or  at  planned  operational  system, 

operational  environment.  Represents  a  major  step  up  from  level  6, 

requiring  the  demonstration  of  an  actual  system 
prototype  in  an  operational  environment. 
Examples  include  testing  the  prototype  in  a  test 
bed  akcraft. 

8.  Actual  system  completed  and  qualified  Technology  has  been  proven  to  work  in  its  final 

through  test  and  demonstration.  form  and  under  expected  conditions.  In  almost 

all  cases,  this  level  represents  the  end  of  true 
system  development.  Examples  include 
developmental  test  and  evaluation  of  the  system 
in  its  intended  weapon  system  to  determine  if  it 
meets  design  specifications. 

9.  Actual  system  proven  through  successful  Actual  application  of  the  technology  in  its  final 

mission  operations.  form  and  under  mission  conditions,  such  as 

those  encountered  in  operational  test  and 
evaluation.  Examples  include  using  the  system 
under  operational  mission  conditions. 
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API.  APPENDIX? 

INFORMATION  TECHNOLOGY  REGISTRATION 


AP7.1.  IT  REGISTRATION 

The  IT  Registry  is  an  enterprise-wide,  web-enabled,  secure  server  operation  via  NIPRNET  and 
SIPRNET.  The  use  of  the  IT  Registry  is  required  for  all  mission  critical  information  systems  and 
mission  essential  information  systems.  The  database  must  be  loaded  in  an  automated  process 
from  the  reporting  agency’s  local  CIO  database  and/or  updated  interactively  on-line  through  the 
secure  web  interface  provided.  After  the  initial  submission,  the  data  shall  be  updated  not  less 
than  quarterly. 

AP7.1.1.  The  following  procedures  are  required  to  obtain  an  account  for  the  IT  Registry: 

AP7.1.1.1.  Register  on  the  NIPRNET  at  https://www.itdb.c3i.osd.mil  or  on  tiie 
SIPRNET  at  http://207.85.97.1 1.  If  all  the  data  is  unclassified,  the  NIPRNET  site  is 
recommended  for  registration. 

AP7.I.1.2.  The  IT  Registry  homepage  provides  a  link  for  new  users  to  register. 

AP7.1.1.3.  Complete  the  application  form  for  new  users. 

AP7.1.1.4.  Upon  verification  of  identity,  the  new  user  will  be  granted  access  to  the 

database. 

AP7.1.2.  DoD  Service  and  Agency  Components  will  be  able  to  update  and  query  the  data 
they  provided  through  a  secure  web  interface.  Each  Service  and  Agency  Component’s  current 
IT  Registry  POC  will  have  authorization  to  provide  user  IDs  and  access  to  the  secure  web 
interface  for  any  user  in  its  management  chain. 

AP7.1.3.  The  DoD  Deputy  Chief  Information  Officer  has  the  responsibility  for  the 
development,  upgrade,  and  maintenance  of  the  IT  Registry.  Direct  questions  and  requests  for 
user  manuals  to  that  organization.  The  IT  Registry  web  site  has  user  manuals  for  download. 
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A .  Report  Title:  The  New  DoD  Regulation  5000.2-R 

B.  DATE  Report  Downloaded  From  the  Internet:  11/14/01 


C.  Report's  Point  of  Contact:  (Name,  Organization,  Address,  Office 
Symbol,  &  Ph  #):  The  Under  Secretary  of  Defense 

3010  Defense  Pentagon 
Washington,  DC  20301-3010 


D.  Currently  Applicable  Classification  Level:  Unclassified 


E.  Distribution  Statement  A:  Approved  for  Public  Release 

F.  The  foregoing  information  was  compiled  and  provided  by: 
DTIC-OCA,  Initials:  _VM_  Preparation  Date  11/14/01 


The  foregoing  information  should  exactly  correspond  to  the  Title,  Report  Number,  and  the  Date 
the  accompanying  report  document.  If  there  are  mismatches,  or  other  questions,  contact  the 
above  OCA  Representative  for  resolution. 


